teoria sobre bases de dados relacionais · teoria sobre sistemas de gestão de bases de dados 1 i....

Teoria sobre Bases de Dados Relacionais

elaborado por Cristina Maria Rodrigues Leitão (Prof.Adjunta)

ESGS, 1999

Indíce

I. Bases de dados relacionais................................................................................................................................. 1

II. Normalização.................................................................................................................................................. 16

III. Diagrama Entidade-Relacionamento (E-R)................................................................................................... 23

IV. SQL................................................................................................................................................................ 38

V. Gestão de privacidade/segurança na base de dados ....................................................................................... 84

VI. Dicionário de Dados...................................................................................................................................... 88

VII. Transacções.................................................................................................................................................. 92

VIII. Concorrência e consistência ..................................................................................................................... 102

IX. Bases de dados distribuídas......................................................................................................................... 111

X. Aspectos físicos de uma base de dados ........................................................................................................ 123

XI. Estruturas Facultativas para melhorar pesquisas ........................................................................................ 136

1Teoria sobre Sistemas de Gestão de Bases de Dados

I. Bases de dados relacionais Um sistema de base de dados relacional é basicamente um mecanismo que mantém registos de dados informatizados. A este corresponde um conjunto de dados interrelacionados e um conjunto de programas para aceder a esses dados. Uma base de dados relacional é um conjunto de dados estruturado de tal forma que possa ser convenientemente utilizado com eficiência por uma grande gama de aplicações. Abordagem tradicional (base de dados não relacional) •Não nos proporcionava tal à vontade na manipulação de dados. •As bases de dados tradicionais eram compostas por um conjunto de ficheiros (não interrelacionados) e um conjunto de programas para a sua manipulação. •Principais riscos (desvantagens)

- Dados inconsistentes e com redundância, impossibilitando a sua manipulação por várias aplicações e ocupando mais memória em disco;

- Dificuldade de acesso aos dados; - Isolamento dos dados; - Problemas de integridade; - Acesso concorrente de vários utilizadores aos mesmos dados; - Sistema de segurança de dados pouco eficaz.

•Serviam o propósito de assistir ou suportar uma função dentro da organização, e elaborar relatórios pré-definidos.

exemplo: uma organização possuía uma base de dados para gestão comercial, uma para gestão de stocks e outra para a contabilidade.

Bases de dados relacionais têm em conta os seguintes factores:

- consistência; - não redundância; - fácil acesso; - acesso concorrente; - integridade dos dados; - segurança dos dados.

•Suporta muitas das funções dentro da organização e dá acesso a informação irregular

exemplo: gestão de stocks, a contabilidade, e a gestão comercial coexistem na mesma base de dados.

•Esta integração de dados, gera informação com características mais complexas, possibilitando maior resposta para a tomada de decisões dentro da organização, sendo relativamente fácil gerar relatórios com informação integrada de várias áreas.


Abstracção de dados Um Sistema de Gestão de Bases de Dados (SGBD), proporciona aos utilizadores uma visão abstracta dos dados. A forma como estes estão armazenados não é a forma como o utilizador os visualiza, existindo três níveis de abstracção de dados. Nível de “visualização” é a forma como o utilizador vê os dados, consoante as suas necessidades. O nível conceptual é a descrição dos dados armazenados e das relações entre eles. O nível físico é a descrição de como os dados são de facto armazenados (estrutura de dados utilizada ao mais baixo nível) Modelos de Dados Conjunto de ferramentas conceptuais para descrever os dados, as relações entre dados, a semântica dos dados e as restrições dos dados. Alguns modelos de dados: 1) Modelos de dados físicos. 2) Modelos lógicos baseados em objectos; 3) Modelos lógicos baseados em registos (records); 1) Modelo de dados Físico Os modelos de dados físicos são usados para descrever os dados ao mais baixo nível. 2) Modelos de dados baseados em objectos Utilizados na descrição dos dados ao nível conceptual e ao nível de “visualização”. Modelos lógicos baseados em objectos mais conhecidos: a) Modelo Entidade-Relacionamento (o mais representativo); b) Modelo binário; c) Modelo de dados semântico; d) Modelo “infológico”.


a) Modelo Entidade-Relacionamento É baseado na percepção de que o mundo real é constituído por dois tipos de objectos: Entidades: objectos existentes que se destinguem uns dos outros; Relacionamentos entre os objectos: associações entre os vários objectos.

FORNECEDOR ARTIGOVENDE1 1

COD_FORNECEDORNOMEMORADA

COD_ARTIGONOME_ARTIGOCOD_FORNECEDOR

COD_ARTIGO

3) Modelos lógicos baseados em registos Utilizados na descrição dos dados ao nível conceptual e ao nível de “visualização”. Modelos lógicos baseados em registos mais conhecidos; a) Modelo em Rede; b) Modelo hierárquico. c) Modelo Relacional a) Modelo em Rede Os dados são representados por meio de registos (records do tipo dos do Pascal) e as relações entre os dados por meio de ligações (links), que funcionam como uma espécie de ponteiros. Os registos de cada base de dados estão organizados como um conjunto de grafos. Exemplo:

João R.Flores Lisboa

Maria R.Direita Santarém

Gertrudes R.Larga Porto

55 100 000

99 200 000

45 250 000

33 300 000


b) Modelo hierárquico Os dados e as relações entre os dados são representados por registos e por ligações (records e links ) tal como no modelo em rede. No entanto, ao contrário do modelo em rede, os registos estão organizados como um conjunto de árvores em vez de um conjunto de grafos. Exemplo:

João R.Flores Lisboa

33 300 000

Maria R.Direita Santarém

Gertrudes R.Larga Porto

55 100 000 99 200 00045 250 000

c) Modelo relacional O Modelo Relacional é um modelo lógico baseado em registos. Neste modelo, os dados e as relações entre os dados são representados por tabelas, e todas as tabelas da base de dados e os seus respectivos atributos e chaves primárias são descritas nele.

ARTIGOCODIGO_ARTIGO NOME_ARTIGO QUANTIDADE CODIGO_FORNECEDOR1 Lápis 15 22 Papel 20 33 Caneta 47 1

FORNECEDORCODIGO_FORNECEDOR NOME_FORNECEDOR1 J.J & Filhos2 Copiconta Lda3 MacInfo Lda

...


Instâncias e Esquemas As bases de dados mudam ao longo do tempo, através da introdução de mais informação ou do agrupamento da informação existente na base de dados. Instancia: conjunto de informação existente numa base de dados num dado instante Esquema da base de dados: estrutura geral da base de dados Podem haver vários esquemas, de acordo com os diferentes níveis de abstracção: • Esquema físico; • Esquema conceptual; • Subesquema. Independência de dados Designa-se Independência dos dados a capacidade de modificar a definição do esquema de dados a um dado nível sem afectar o esquema no nível mais alto seguinte. Independência Física dos dados: Capacidade de modificar o esquema físico sem que os programas de aplicações tenham que ser re-escritos. Independência Lógica dos dados: Capacidade de modificar o modelo conceptual sem que os programas de aplicações tenham que ser re-escritos.


Modelo relacional O Modelo Relacional é um modelo lógico baseado em registos. Neste modelo, os dados e as relações entre os dados são representados por tabelas, e todas as tabelas da base de dados e os seus respectivos atributos e chaves primárias são descritas nele. Tabelas Ao nível conceptual os dados são armazenados em tabelas que representam entidades de informação relevante na base de dados e relacionamentos entre as entidades. Uma tabela numa base de dados de um armazém pode ser, por exemplo, a entidade fornecedor. Cada fornecedor pode ter vários atributos tais como o nome, morada, n.º contribuinte etc. Estes atributos das entidades, têm o nome de campos ou atributos dentro das tabelas. Existem vários fornecedores guardados dentro da tabela que correspondem a registos ou linhas diferentes dentro da mesma. A figura seguinte ilustra um exemplo de uma tabela: Exemplo:

FORNECEDORNOME LOCALIDADE N_CONTRIBUINTEJ.J & Filhos Lisboa 152358945Copiconta Lda Porto 456789236MacInfo Lda Coimbra 478951238

• Cada coluna deste exemplo, corresponde a um campo ou atributo da tabela e

cada linha corresponde a um registo ou linha. • No modelo relacional todos os dados, assim como o relacionamento entre eles, são

representados por um conjunto de tabelas. • Cada tabela tem um nome pelo qual é referenciada. • Cada coluna tem um nome, que se refere a um atributo ou campo dentro da

mesma. • Cada linha ou registo da tabela representa uma entidade única ou um

relacionamento entre entidades. • O domínio de todos os atributos deve ser constituído por valores atómicos.


• A ordem pela qual aparecem os atributos (colunas) não é importante e pode ser

alterada sem que isso mude o significado do tuplo. • A ordem pela qual aparecem os registos (linhas) não é importante e pode ser

alterada sem que isso mude o significado do tuplo. Cada tuplo representa uma entidade (ou relacionamento) e este é apenas determinado pelos valores existentes em cada campo, e não pela sua posição na tabela.

Chave primária Cada tabela deve ter uma chave primária, que é um campo ou conjunto de campos que permitem identificar de forma unívoca qualquer registo da tabela. Os campos da chave primária têm sempre um valor unívoco para qualquer registo da tabela. Se algum dos valores que correspondem à chave primária for nulo, então essa chave deixa de ter um valor unívoco. No acto da manipulação de dados é necessário assegurar que os valores que correspondem à chave primária não são nulos. Exemplo:

FORNECEDORCODIGO_FORNECEDOR NOME LOCALIDADE N_CONTRIBUINTE1 J.J & Filhos Lisboa 1523589452 Copiconta Lda Porto 4567892363 MacInfo Lda Coimbra 478951238

chave primária

Como pode existir mais do que um fornecedor com o mesmo nome, então cada fornecedor deverá ter um código, sendo então o campo CODIGO_FORNECEDOR a chave primária da tabela. Outra possível chave primária seria o campo N_CONTRIBUINTE, visto cada fornecedor ter um número de contribuinte diferente. Às diferentes alternativas de chaves primárias chamam-se chaves candidatas.


Chave forasteira As chaves forasteiras identificam relacionamentos entre entidades. Uma chave forasteira é um campo da tabela que é chave primária noutra tabela. Se a chave primária da tabela FORNECEDOR for o CODIGO_FORNECEDOR, então este campo faz a relação entre ARTIGO e FORNECEDOR e é considerado uma chave forasteira na tabela ARTIGO. É esta chave que determina qual o artigo que o fornecedor vende.

ARTIGOCODIGO_ARTIGO NOME_ARTIGO QUANTIDADE CODIGO_FORNECEDOR1 Lápis 15 22 Papel 20 33 Caneta 47 1

FORNECEDORCODIGO_FORNECEDOR NOME_FORNECEDOR1 J.J & Filhos2 Copiconta Lda3 MacInfo Lda

...

chave primáriachave forasteira

Exercício: Base de dados de Artigos vendidos por fornecedores, onde se pode retirar a seguinte informação: - Quais os artigos vendidos por um determinado fornecedor; - Qual o preço que um fornecedor pratica para um determinado artigo; - Quais os fornecedores que fornecem determinado artigo.


Integridade dos dados Numa base de dados é necessário manter a integridade dos dados. No modelo relacional existem três tipos de integridade: Integridade de entidade - os valores dos atributos que correspondem à chave primária não podem ser nulos nem iguais a outros já existentes na tabela. Integridade referencial - o valor da chave forasteira de uma tabela deve referenciar sempre uma chave primária existente noutra tabela. O facto da chave forasteira ser nula significa que não referencia nenhuma chave primária noutra tabela. Conformidade com as regras do negócio - Assegura-se definindo restrições específicas da situação a tratar destinadas a garantir que os valores a guardar nas tabelas são válidos e com significado. O desenhador da base de dados pode garantir que as regras de integridade são cumpridas numa base de dados através da validação de dados no acto de introdução, eliminação ou alteração dos registos. Em Oracle e em outras bases de dados algumas destas regras podem logo ser definidas através da criação das tabelas. Se forem bem definidas as chaves primárias, as chaves forasteiras e as restrições em cada tabela, o próprio motor da base de dados Oracle não permite manipular dados na base de dados que violem as regras de integridade. Objectivos a atingir num projecto de concepção de uma base de dados:

• Permitir guardar na base de dados todos os dados relevantes; • Eliminar todos os dados redundantes; • Manter o número de relações reduzido a um mínimo; • Normalizar todas as relações.

Objectivo 1: • Determinar todos os objectivos que são relevantes na base de dados; • Determinar quais as relações necessárias; • Decidir quais os atributos a colocar em cada relação (tabela).


Objectivo 2: Outro dos objectivos do desenho do modelo conceptual é a eliminação de todos os dados redundantes, sendo necessário destinguir entre dados redundantes e dados duplicados. Podem existir dados duplicados numa tabela que não são necessariamente redundantes. No exemplo que se segue existem dois fornecedores diferentes que se encontram sediados na mesma localidade (Lisboa). Como vemos, o nome da localidade está repetido. Contudo, não estamos perante uma redundância porque se a referência fosse omitida deixaria de ser possível determinar a localidade de um dos fornecedores. Trata-se pois, de um caso de duplicação de dados.

FORNECEDORCODIGO_FORNECEDOR NOME_FORNECEDOR LOCALIDADE1 J.J & Filhos Lisboa2 Copiconta Lda Porto3 MacInfo Lda Coimbra4 InforPaper Lisboa

...

Os dados redundantes são dados que estão repetidos e que podem ser eliminados sem darem origem à perda de informação. Nas duas tabelas que se seguem é ilustrado um caso de redundância entre ambas. Na tabela FORNECEDOR existem os campos LOCALIDADE e CODPOSTAL e na mesma base de dados existe uma tabela que descreve quais as localidades correspondentes a cada código postal. Neste caso o campo localidade na tabela FORNECEDOR é redundante, pois na tabela COD_POSTAL pode ser consultada a localidade dum fornecedor através do seu código postal.

FORNECEDORCODIGO_FORN NOME_FORN LOCALIDADE CODPOSTAL1 J.J & Filhos Lisboa 10002 Copiconta Lda Porto 40003 MacInfo Lda Coimbra 30004 InforPaper Lisboa 1000

dados redundantesAtravés do CODPOSTA L na tabelaFORNECEDOR pode ser consultada aLOCA LIDA DE na tabelaCOD_ POSTA L.


Como eliminar dados redundantes: Se existisse só a tabela FORNECEDOR, a solução mais correcta para eliminar dados redundantes seria fragmentar a tabela em duas (FORNECEDOR e COD_POSTAL).

FORNECEDORCODIGO_FORN NOME_FORN CODPOSTAL1 J.J & Filhos 10002 Copiconta Lda 40003 MacInfo Lda 30004 InforPaper 1000

COD_POSTALCODPOSTAL LOCALIDADE1000 Lisboa4000 Porto3000 Coimbra

Objectivo 3: Manter o número de relações reduzido ao mínimo, de molde a simplificar a base de dados do ponto de vista do utilizador. Objectivo 4: Normalizar todas as relações.


Gestor da base de dados Módulo de programas que constitui o interface entre os dados de baixo nível contidos na base de dados e os programas de aplicação e os pedidos feitos ao sistema. Algumas tarefas do gestor da base de dados:

• Interacção com o gestor de ficheiros; • Verificação e manutenção da integridade dos dados; • Verificação e manutenção da segurança dos dados; • Salvaguarda dos dados e a recuperação em caso de falha; • Controlo da concorrência.

Administrador da base de dados Pessoa (ou grupo de pessoas: conselho de administração) que tem o controlo central dos dados e dos programas que acedem aos dados: Algumas das funções do administrador da base de dados:

• Definição do esquema; • Definição da estrutura de armazenamento e do método de acesso; • Modificação da organização física do esquema; • Concessão de autorizações para acesso a dados; • Especificação de restrições de integridade.


SQL O SQL (Structured Query Language), é a linguagem standard para bases de dados relacionais, e é através desta linguagem que são feitos todos os acessos à base de dados. A ideia de base do SQL é a de possibilitar aceder a informação só através de instruções, sem a necessidade de programas modulares. Existem dois tipos de comandos SQL: DDL (Linguagem de Definição de Dados) Os comandos LDD são utilizados para definir o esquema da base de dados, ou seja, criar, alterar ou eliminar os objectos da base de dados.

Objectos da base de dados: tabelas, vistas, triggers, sequências, índices, procedimentos e todos os outros elementos que fazem parte da base de dados.

Os comandos LDD principais são os seguintes: CREATE - comando utilizado para criar objectos da base de dados; ALTER - comando utilizado para alterar objectos da base de dados; DROP - comando utilizado para eliminar objectos da base de dados. DML (Linguagem de Manipulação de Dados). Os comandos LMD são utilizados para aceder à informação armazenada na base de dados e podem inserir, alterar, eliminar ou consultar informação na base de dados. Os comandos LMD principais são os seguintes: INSERT - Comando usado para inserir novos registos em tabelas; UPDATE - Comando usado para alterar registos já existentes em tabelas; DELETE - Comando usado para eliminar registos em tabelas; SELECT - Comando utilizado para interrogar a base de dados. DCL (Linguagem de Controlo de Dados). Os comandos DCL são utilizados para a gestão da segurança na base de dados. GRANT - Comando que dá permissões aos utilizadores; REVOKE - Comando que retira permissões aos utilizadores;


Projecto de uma base de dados I. Análise de Requisitos

1. Descrição do problema a tratar 2. Relatório de Definição e Planificação do Projecto

II. Criação de Esquema de Dados

1. Diagrama de Entidade-Relacionamento (E-R) 2. Passagem de E-R para Esquema de Dados 3. Criação da Base de Dados em SQL

Criação de tabelas Gestão de espaço na base de dados

Criação de vistas Criação de sequências Gestão de privacidade/segurança na base de dados

Privilégios Criação de roles

Criação do esquema Criação de sinónimos Criação de triggers

III. Projecto das aplicações clientes

1. Diagramas de Fluxos de Dados 2. Desenho de aplicações 3. Implementação de aplicações

Implementação de forms Implementação de relatórios

Todos as fases referentes à criação do esquema de dados podem ser efectuadas simultaneamente com as do projecto de aplicações cliente.


Análise de Requisitos 1. Análise da situação a tratar

Esta análise recorre a vários tipos de acções:

Entrevistas aos utilizadores; Observações aos formulários e relatórios utilizados no sistema actual; Análises aos ficheiros e bases de dados já existentes.

2. Descrição do sistema e todos os seus processos 3. Levantamento das necessidades e objectivos do novo sistema. 4. Relatório de Definição e Planificação do Projecto

Documento utilizado para a proposta do novo sistema a ser desenhado. Este documento é por vezes considerado um do mais importantes no desenho de um sistema, pois é ele o veículo principal para a comunicação entre os utilizadores e os profissionais informáticos. Neste relatório deve constar:

• A definição dos objectivos do sistema; • A definição das principais funções; • A indicação de ambientes de Processamento e de Desenvolvimento; • A indicação do ambiente de processamento; • A indicação dos benefícios esperados; • A estimativa da duração e dos recursos da fase de desenho conceptual.

5. Modelo de dados (Modelo Conceptual)

• Conjunto de ferramentas conceptuais para descrever os dados ao nível conceptual, as relações entre os dados e a sua semântica. • Representação da estrutura e relações do que deverá ser incluído na base de dados para satisfazer as necessidades de informação dos utilizadores. • Base para todos os processos posteriores na construção de uma base de dados.


II. Normalização Dependência funcional entre os dados Diz-se, que B é funcionalmente dependente de A, se a cada valor de A estiver associado um e só um valor de B. Forma de representação: A→B. Diz-se, que A é o determinante de B, se A→B e se B não for funcionalmente dependente de um subconjunto de A. A identificação das dependências funcionais é feita através das propriedades dos campos. Exemplo (Depêndencia Funcional): Para a tabela FORNECEDOR: A morada do fornecedor é funcionalmente dependente do código do fornecedor. O código do fornecedor é a chave primária que é unívoca, pode-se determinar a sua morada através deste código, visto que cada fornecedor só pode ter uma morada. Diz-se então que a morada é funcionalmente dependente do código do fornecedor, mas o código do fornecedor não é funcionalmente dependente da morada. Podem existir vários fornecedores com a mesma morada, apesar de cada um ter um código diferente.


Normalização de dados A normalização representa um processo formal de eliminar redundância nas tabelas. • Este processo identifica a localização correcta de cada atributo e a estrutura

correcta das relações existentes numa base de dados. • No processo de normalização de dados existem várias formas normais que

representam as diferentes regras. • Embora uma tabela esteja normalizada, esta pode ainda possuir propriedades não

desejadas que provocam um mau funcionamento na base de dados. • Na maioria dos casos, a normalização até à 3FN é suficiente, mas existem casos

em que é necessário atingir formas normais mais elevadas ou até parar antes da 3FN.

• O desenhador deve reconhecer quando a base de dados possui propriedades não

desejadas para determinar qual a forma normal que termina o processo de normalização da relação.

• O processo de normalização raramente percorre todas as formas normais.

Frequentemente o analista reconhece, por experiência própria, que uma dada relação não está normalizada, e coloca-a directamente na 3FN ou na FNBC.


1ª forma normal (1FN) A 1ª forma normal de dados é muitas vezes referida como a Relação Universal. Uma relação está em 1ª forma normal (1FN) quando:

• os domínios de todos os seus atributos contêm apenas valores atómicos; • não existem atributos repetitivos descrevendo a mesma característica,

atributos estes que podem existir mais do que uma vez em cada registo.

FORNECEDOR

CODIGO_FORN NOME_FORN ARTIGOS PREÇOS 1 J.J & Filhos lapis, caneta 10,50 2 Copiconta Lda papel, tinteiro 100,1050 3 MacInfo Lda caneta, papel 60,150

valores não atómicos

No exemplo acima ilustrado, os domínios dos campos ARTIGOS e PREÇOS não contém valores atómicos, pelo que a tabela não está na 1FN.

FORNECEDORCODIGO_FORN NOME_FORN ARTIGO1 ARTIGO2 PREÇO1 PREÇO21 J.J & Filhos lapis caneta 10 502 Copiconta Lda papel tinteiro 100 10503 MacInfo Lda caneta papel 60 150

atributos do mesmo tipo repetidos

Os valores de ARTIGO e PREÇO já são valores atómicos, mas estão repetidos na mesma tabela o mesmo tipo de atributos (ARTIGO1, ARTIGO2, PREÇO1, PREÇO2), o que implica que cada fornecedor só pode vender dois artigos. Na Relação Universal ou 1FN, as tabelas contém todos os atributos de interesse para a base de dados e podem ser guardados todos os dados da base de dados. A tabela FORNECEDOR em 1FN. Neste caso, cada fornecedor pode vender N artigos e para cada artigo pode praticar um único preço.

FORNECEDORCODIGO_FORN NOME_FORN ARTIGO PREÇO1 J.J & Filhos lapis 101 J.J & Filhos caneta 502 Copiconta Lda papel 1002 Copiconta Lda tinteiro 10503 MacInfo Lda caneta 60


2ª forma normal (2FN) Uma tabela está em 2FN quando está na 1FN e todos os campos que não fazem parte da chave estão funcionalmente dependentes da chave primária. Se, no exemplo anterior, o atributo CODIGO_FORN for considerado como a chave primária, pode-se dizer que o atributo NOME_FORN depende inteiramente da chave, mas o atributo PRECO não só depende do atributo CODIGO_FORN mas também depende do atributo ARTIGO. Existe, então, o atributo PRECO que não depende totalmente da chave, o que significa que a tabela não está na 2FN. A forma de passar esta relação para 2FN é passá-la para as duas tabelas que estão representadas no exemplo seguinte. Ao processo de dividir os atributos de uma tabela em duas ou mais tabelas dá-se o nome de decomposição.

FORNECEDORCODIGO_FORN NOME_FORN1 J.J & Filhos2 Copiconta Lda3 MacInfo Lda

FORNECEDOR_ARTIGOCODIGO_FORN ARTIGO PREÇO1 lápis 101 caneta 502 papel 1002 tinteiro 10503 caneta 603 papel 150

Se for considerada a chave concatenada COD_FORN+ARTIGO como chave primária da tabela FORNECEDOR_ARTIGO, então o campo PREÇO já depende inteiramente da chave. Para saber o preço do artigo é sempre necessário saber qual o fornecedor que o vende.


3ª forma normal (3FN) Uma tabela está em 3FN quando está em 2FN e todos os atributos são funcionalmente dependentes da chave primária e somente dela. Noutras palavras, não podem existir dependências funcionais transitivas na 3FN. O termo dependência transitiva significa que um atributo não é a chave primária da tabela mas no entanto identifica outro atributo. No exemplo seguinte, os campos NOME_FORN, LOCALIDADE e CODPOSTAL são funcionalmente dependentes da chave primária COD_FORN. O campo LOCALIDADE também é funcionalmente dependente do campo CODPOSTAL, o que significa que existe uma dependência transitiva. O campo CODPOSTAL é funcionalmente dependente do campo COD_FORN e por sua vez o campo LOCALIDADE é funcionalmente dependente do campo CODPOSTAL. Como existe dependência transitiva, esta tabela não está em 3FN.

FORNECEDORCODIGO_FORN NOME_FORN LOCALIDADE CODPOSTAL1 J.J & Filhos Lisboa 10002 Copiconta Lda Porto 40003 MacInfo L.da Coimbra 3000

Ao passar a tabela para 3FN os dados serão distribuídos por duas tabelas diferentes, como ilustra o exemplo seguinte.

FORNECEDORCODIGO_FORN NOME_FORN CODPOSTAL1 J.J & Filhos 10002 Copiconta L.da 40003 MacInfo L.da 30004 InforPaper 1000



Verificar o resultado final após a normalização • A mesma dependência funcional não deve aparecer em mais do que uma relação; • Não devem existir relações redundantes. Concepção de bases de dados Do particular para o geral (bottom-up)

1. Normalização; 2. Modelo.

(Pequenos projectos, 6-10 tabelas) Do geral para o particular (top-down)

1. Entidade-Relacionamento; 2. Análise de cardinalidade e participações; 3. Modelo

(Grandes projectos)


III. Diagrama Entidade-Relacionamento (E-R) • Metodologia mais utilizada para desenvolvimento top-down (desenvolvimento do

geral para o particular), porque começa por identificar os objectos principais do sistema, e só depois identifica as interacções entre eles e as suas propriedades.

• É utilizado para interpretar, especificar, e documentar as necessidades para o

processamento da base de dados. • Este foi introduzido por Peter Chen em 1976 e tem sofrido muitas alterações desde

então. • Um modelo E-R é um modelo lógico baseado em objectos: entidades e

relacionamentos entre as entidades. • Para um bom entendimento deste modelo é necessário definir os termos entidade,

bem como atributo, identificador e relacionamento. Exemplo de um E-R:

FORNECEDOR ARTIGO VENDE 1 1

COD_FORNECEDOR NOME MORADA

COD_ARTIGO NOME_ARTIGO COD_FORNECEDOR

COD_ARTIGO


Entidade Uma entidade é algo que pode ser identificado no ambiente do utilizador, ou seja algo que é importante guardar ou manipular informação por parte dos utilizadores do sistema a ser desenhado. Um exemplo de uma entidade para o sistema de Gestão de Stocks, pode ser o fornecedor J.J. & Filhos, o centro de custo Projecto J ou o artigo lápis. classe da entidade

• Conjuntos de entidades do mesmo tipo • É uma forma geral de descrever algo, como FORNECEDOR • Normalmente é utilizada a terminologia entidade para referenciar uma classe

de entidade. instância de entidade

Representação de uma entidade particular, como o FORNECEDOR J.J. & Filhos. Uma classe da entidade (classe de entidade) é representada através de um rectângulo. Exemplo de uma entidade:

FORNECEDOR

Atributo As entidades contêm atributos que descrevem as suas características. Alguns exemplos de atributos para a entidade FORNECEDOR são o nome, a morada, o telefone, etc. O modelo E-R, pressupõe que todas as instâncias de uma determinada entidade têm os mesmos atributos.


Relacionamento As entidades, por elas próprias, não são suficientes para representarem o sistema. Elas representam entidades no sistema, mas não dizem nada sobre a forma de interacção entre as entidades. Para representar a interacção entre as entidades do sistema, é necessário representar os relacionamentos. Como os FORNECEDORES vendem ARTIGOS, então esta é a forma das duas entidades se relacionarem. Um relacionamento entre entidades é representado por um triângulo a fazer a ligação entre as duas entidades. Exemplo de um relacionamento entre entidades:

FORNECEDOR ARTIGOVENDE

Uma instância deste relacionamento pode ser o FORNECEDOR J.J. & Filhos que vende o ARTIGO lápis. O conjunto de relacionamento é formado por todas as instancias do relacionamento entre artigos e fornecedores.


Diagrama de ocorrências Para ilustrar a forma de interacção entre entidades, é muitas vezes utilizado um diagrama de ocorrências. Neste diagrama existem linhas a unirem pares de ocorrências de entidades através de um relacionamento. Exemplo de diagrama de ocorrências:

Este diagrama ilustra quatro fornecedores e quatro artigos. As linhas unindo os pares mostram quais os fornecedores a venderem os diferentes artigos e quais os artigos a serem vendidos pelos diferentes fornecedores.

f1•f2•f3•f4•

•a1•a2•a3•a4

Cardinalidade Através dos diagramas de ocorrências pode ser determinada a cardinalidade dos relacionamentos, a qual define o número de relacionamentos entre duas entidades. O exemplo anterior mostra que cada fornecedor pode vender mais do que um artigo e que cada artigo pode ser vendido por mais do que um fornecedor. Diz-se que este relacionamento tem o grau de M:N. Num diagrama E-R a cardinalidade é identificada escrevendo o grau sobre a linha que une as duas entidades à relação, conforme o diagrama E-R, como no exemplo seguinte.

FORNECEDOR ARTIGOVENDEM N


O diagrama seguinte ilustra um sistema em que cada entidade pode participar num só relacionamento, ou seja, cada fornecedor só pode vender um artigo e cada artigo só pode ser vendido por um fornecedor. Neste caso o relacionamento é de grau 1:1.

f1•f2•f3•f4•

•a1•a2•a3•a4

O diagrama seguinte ilustra um sistema em que entidades de uma classe podem participar em mais do que um relacionamento. No exemplo dado, os fornecedores podem vender mais do que um artigo, mas nenhum artigo pode ser vendido por mais do que um fornecedor. Diz-se que este tipo de relacionamento tem um grau de 1:N. Aqui um fornecedor pode fornecer N artigos, mas cada artigo só pode ser vendido por um fornecedor.

f1•f2•f3•f4•

•a1•a2•a3•a4

Para este caso o diagrama E-R é o seguinte:

FORNECEDOR ARTIGOVENDE1 N

Se ocorrer o caso inverso, em que cada fornecedor só pode vender um artigo, mas cada artigo pode ser vendido por mais do que um fornecedor, então a cardinalidade será de grau N:1.


Participação Este conceito determina se uma entidade deve ou não participar num relacionamento. O diagrama seguinte é um exemplo duma base de dados de um armazém. Não é forçoso que todos os fornecedores já tenham vendido artigos. No entanto, todos os artigos registados na base de dados tiveram que ser fornecidos por fornecedores.

f1•f2•f3•f4•

•a1•a2•a3•a4

Diz-se então que existe participação obrigatória da entidade ARTIGO e participação opcional da entidade FORNECEDOR. Participação obrigatória é representada através de um círculo fechado ao lado da entidade e participação opcional é representada pela ausência do círculo, como ilustra o diagrama seguinte.


Se forem bem definidas as regras de cardinalidade e participação, assegura-se que os constrangimentos de integridade dentro da base de dados serão preservados.


Identificador Cada instância de uma entidade tem um ou mais atributos que a identifica univocamente. Ao atributo que é escolhido para identificar a entidade univocamente dá-se o nome de identificador. Exemplo:

O fornecedor pode ser identificado pelo seu n.º de contribuinte ou pelo seu código de fornecedor. Se fosse considerado o nome do fornecedor como identificador do fornecedor, corria-se o risco de existir mais do que um fornecedor com o mesmo nome e o identificador perderia as características de identificação unívoca.

Muitas vezes os identificadores são atributos escolhidos só com o objectivo de identificar a entidade, como no exemplo anterior em que foi criado o código do fornecedor. Poderão existir também identificadores compostos por mais do que um atributo, e são, na maioria dos casos, identificadores de relacionamentos. Nenhum dos atributos que compõe um identificador composto pode ser excluído sem destruir a propriedade de identificação unívoca. Exemplo:

Para identificar o relacionamento entre a entidade ARTIGO e a entidade FORNECEDOR são necessários os identificadores de ambas as entidades. O conjunto de ocorrências de COD_FORNECEDOR+COD_ ARTIGO contém toda a informação identificando qual o artigo que cada fornecedor vende.

Os identificadores são representados em conjunto com os outros atributos e distinguem-se pelo facto de serem sublinhados.


COD_FORNECEDORNOMEMORADA

COD_ARTIGONOME_ARTIGOCOD_FORNECEDOR

COD_ARTIGO


Subconjuntos de entidades (papeis) (Extensão ao modelo E-R. ) Existem casos em que no mesmo sistema a mesma entidade pode ser tratada de formas diferentes, ou seja existem subconjuntos diferentes da mesma entidade. Estes subconjuntos podem ter atributos diferentes e relacionamentos diferentes com outras entidades. Exemplo: Num sistema de Contabilidade em estudo são enviados pelos fornecedores documentos para serem liquidados, podendo esses documentos ser facturas ou Vendas a Dinheiro. Como o tratamento das facturas dentro da Contabilidade é diferente do tratamento das Vendas a Dinheiro, pode determinar-se que a entidade DOCUMENTO tem dois subconjuntos diferentes, FACTURA e VENDA_DIN. A forma de representar estes dois papeis é através de linhas com setas da entidade fonte para os diferentes subconjuntos. A entidade fonte, que neste caso é o DOCUMENTO, vai manter todos os atributos comuns às facturas e Vendas a Dinheiro e o seu identificador é o N.º DOCUMENTO. Cada um dos subconjuntos deve também manter como identificador o N.º DOCUMENTO, apesar de possuir outros atributos específicos. As entidades que representam os subconjuntos são tratadas como entidades normais, às quais se aplicam as regras já conhecidas.

DOCUMENTO

FACTURA VENDA_DIN

N_DOCUMENTODATAVALOR

N_DOCUMENTON_VENDA_DIN

N_DOCUMENTON_FACTURA


Regras para desenhar diagramas E-R Um dos critérios é considerar o diagrama E-R como uma boa ferramenta de comunicação e assim assegurar que todos os dados do sistema estão incluídos e bem representados. O diagrama estrutura os dados de forma normalizada. Isto nem sempre é conseguido, pelo qual é necessário ter cuidado com o desenho das tabelas no Esquema de Dados. Não existem passos específicos para desenhar diagramas E-R com as características pretendidas, mas existem algumas regras que devem ser respeitadas para ajudar o desenhador.

• Como o diagrama vai ser utilizado como um meio de comunicação, então este deve ser fácil de interpretar e recorre a nomes simples. Os nomes das entidades devem ser substantivos sugestivos, enquanto os nomes dos relacionamentos devem ser verbos ou proposições. As entidades ARTIGO e FORNECEDOR são estáticas e pouco significativas, mas através do relacionamento VENDE pode ser ilustrada a actividade entre ARTIGO e FORNECEDOR;

• Pode existir mais do que um relacionamento entre duas entidades para uma

melhor visualização do sistema; • O sistema a ser modelado nunca deve ser incluído como entidade no diagrama.

Por exemplo, no modelo de dados do sistema de Armazém nunca deve ser utilizada a entidade ARMAZEM.


Esquema de Dados A elaboração do Esquema de Dados constitui a fase de desenho da base de dados. O Esquema de Dados é um modelo lógico baseado em registos e é derivado do diagrama E-R. Neste esquema, os dados e as relações entre os dados são representados por tabelas, e todas as tabelas da base de dados, os seus atributos e as suas chaves primárias são descritas nele. O seguinte fragmento do Esquema de Dados, utilizado para as aplicações em estudo, descreve a tabela CEN_CUSTO.

CEN_CUSTO(COD_CEN, C_DESC) Como já foi referido, na maioria dos casos, o desenho diagrama E-R deve ser seguido pela elaboração do Esquema de Dados. É necessário utilizar algumas regras para fazer a conversão do diagrama E-R para o Esquema de Dados. O diagrama E-R nem sempre se converte em tabelas normalizadas porque existem muitas vezes erros nos diagramas E-R, para além de que o modelo E-R pode utilizar alguma construção só para melhorar a sua clareza em descrever os dados. Por isso, é sempre necessário verificar se as tabelas que derivam do diagrama E-R estão normalizadas. Durante a conversão é necessário manter os objectivos a atingir num projecto de concepção de uma base e que passamos a enumerar:

• Permitir guardar na base de dados todos os dados relevantes; • Eliminar todos os dados redundantes; • Manter o número de relações reduzido a um mínimo; • Normalizar todas as relações.

Vejamos então as regras que visam alcançar estes objectivos.


• Regra n.º 1 Se existir um relacionamento binário entre duas entidades com participação obrigatória em ambas e a sua cardinalidade for de grau 1:1, então é necessário definir apenas uma tabela. A chave primária dessa relação pode ser o identificador de qualquer uma das entidades.


FORNECEDOR(COD_FORN, COD_ARTIGO, FMORADA, QUANTIDADE)

Na definição anterior foi considerado o código do fornecedor como a chave primária, mas também pode ser considerado o código do artigo como no exemplo que se segue.

ARTIGO(COD_ARTIGO, COD_FORN, FMORADA, QUANTIDADE) • Regra n.º 2 Se existir um relacionamento binário entre duas entidades com participação obrigatória em uma das entidades e a sua cardinalidade for de grau 1:1, então é necessário definir duas tabelas. O identificador de cada entidade deve ser a chave primária na tabela correspondente. A chave primária da entidade com participação opcional tem de ser usada como atributo na tabela correspondente à entidade cuja participação é obrigatória. Este atributo é uma chave forasteira,. pois este é uma chave primária na outra tabela e tem como objectivo relacionar as duas tabelas.


FORNECEDOR(COD_FORN, NOME_FORN, FMORA DA , FLOCA L)

A RTIGO(COD_A RTIGO, NOME_A RTIGO, QUA NTIDA DE, COD_FORN)


• Regra n.º 3 Se existir um relacionamento binário entre duas entidades com participação opcional em ambas as entidades e a sua cardinalidade for de grau 1:1, então é necessário definir três tabelas. O identificador de cada entidade serve como chave primária na tabela correspondente. A tabela que corresponde ao relacionamento entre as duas entidades tem entre os seus atributos os identificadores de ambas as entidades. Os atributos que compõe o relacionamento são chaves forasteiras, pois estes são chaves primárias das outras duas tabelas e têm como objectivo relacionar as duas tabelas.



A RTIGO(COD_A RTIGO, NOME_A RTIGO, QUA NTIDA DE)

FORNECEDOR_A RTIGO(........, COD_FORN, COD_A RTIGO)


• Regra n.º 4 Se existir um relacionamento binário entre duas entidades de grau 1:N com participação obrigatória do lado N, então é necessário definir duas tabelas. É de salientar que é irrelevante para a definição do número de tabelas o tipo de participação do lado 1. O identificador de cada entidade deve ser a chave primária na tabela correspondente. A chave primária da entidade do lado 1 é utilizada como campo na tabela correspondente à entidade do lado N, sendo este campo uma chave forasteira.



A RTIGO(COD_A RTIGO , NOME_A RTIGO, QUA NTIDA DE, COD_FORN)

• Regra n.º 5 Se existir um relacionamento binário entre duas entidades de grau 1:N com participação opcional do lado N, então é necessário definir três tabelas. É de salientar que é irrelevante para a definição do número de tabelas o tipo de participação do lado 1. O identificador de cada entidade deve ser a chave primária na tabela correspondente. A tabela que corresponde ao relacionamento entre as duas entidades tem entre os seus campos os identificadores de ambas as entidades.




FORNECEDOR_A RTIGO(.............., COD_FORN, COD_A RTIGO)


• Regra n.º 6 Se existir um relacionamento binário entre duas entidades de grau M:N, é sempre necessário definir três tabelas qualquer que seja o tipo de participação. O identificador de cada entidade deve ser a chave primária na tabela correspondente. A tabela que corresponde ao relacionamento entre as duas entidades tem entre os seus campos os identificadores de ambas as entidades.




FORNECEDOR_A RTIGO(..............,COD_FORN, COD_A RTIGO)


• Regra n.º 7 Se existir um relacionamento trinário (ou superior) entre três entidades de grau M:N:P independentemente dos tipos de participação, é sempre necessário definir uma tabela para cada entidade e outra tabela para o relacionamento entre as entidades. O identificador de cada entidade serve como chave primária na tabela correspondente. A tabela que corresponde ao relacionamento tem entre os seus campos os identificadores de todas as entidades.

FORNECEDOR ARTIGOVENDEN P

CEN CUSTO

M

FORNECEDOR(COD_FORN, NOME_FORN, FMORADA, FLOCAL)

ARTIGO(COD_ARTIGO, NOME_ARTIGO, QUANTIDADE)

CEN_CUSTO (COD_CEN, C_DESC)

F_A_C (..............., COD_FORN, COD_ARTIGO, COD_CEN)


IV. SQL Tipos de dados em SQL (Oracle) • CHAR(w) cadeias de caracteres até w=256 caracteres • VARCHAR(w) cadeias de caracteres de comprimento variável até w=256

caracteres • NUMBER(w) Valores numéricos com/sem sinal até w=38 dígitos

significativos • NUMBER(w,d) Valores numéricos com w dígitos significativos e d dígitos

na parte decimal • DATE datas (a informação da hora também é armazenada) • LONG idêntico a char mas com o comprimento máximo até (2

Gbytes no Oracle). Não se pode definir mais que uma coluna LONG por tabela.

Criação de uma tabela CREATE TABLE <nome de tabela> (nome_coluna tipo(tamanho) [<restrições de integridade>], (nome_coluna tipo(tamanho) [<restrições de integridade>], ......); Exemplo: CREATE TABLE DOCUMENTO (N_DOC NUMBER(7) PRIMARY KEY, DATA_LANC DATE NOT NULL, COD_ORC CHAR(5) NOT NULL, COD_RUB CHAR(8) NOT NULL, DATA_DOC DATE, VALOR NUMBER(12,2) NOT NULL, F_D CHAR(1) CHECK (F_D='F' OR F_D='D'), NUMDOC NUMBER(9), COD_FORN NUMBER(4) NOT NULL, COD_CEN NUMBER(5) NOT NULL, NREQUIS NUMBER(7), OBS CHAR(60), NUM_R_F NUMBER(6), DATA_PAG DATE);


Restrições de Integridade Condições a que os valores nas colunas/tabelas devem obedecer. Integridade de entidade; Integridade referencial; Conformidade com as regras do negócio; Exemplo: Garantir que a nota de um aluno nunca é inferior a 0 nem superior a 20. Parâmetros de restrições CONSTRAINT Especifica o nome de uma restrição. É opcional e só útil em casos de erro. NULL/NOT NULL Específica que uma coluna ou grupos de colunas não possam conter valores nulos. UNIQUE Específica que uma coluna ou grupos de colunas só possam conter valores unívocos. PRIMARY KEY (coluna, ...) Específica que uma coluna ou grupos de colunas formam uma chave primária.. FOREIGN KEY (coluna, ...) REFERENCES tabela(coluna, ....) Específica que uma coluna ou grupos de colunas formam uma chave forasteira.. CHECK Especifica uma condição a verificar para que o registo possa existir na tabela.


Tipos de Restrições Restrições de tabela - aplica-se a uma ou mais colunas. Restrições de coluna - aplica-se a uma só coluna. Exemplo: CREATE TABLE GRUPO (COD_GRUPO NUMBER(2) PRIMARY KEY, GDESC VARCHAR2(25) NOT NULL, S_COD_FAMILIA NUMBER(3)); CREATE TABLE FAMILIA (COD_FAMILIA NUMBER(3), COD_GRUPO NUMBER(2), FDESC VARCHAR2(25) NOT NULL, S_COD_ARTIGO NUMBER(3), PRIMARY KEY(COD_GRUPO,COD_FAMILIA), FOREIGN KEY (COD_GRUPO) REFERENCES GRUPO(COD_GRUPO)); CREATE TABLE ARTIGO (COD_ARTIGO NUMBER(3), COD_FAMILIA NUMBER(3), COD_GRUPO NUMBER(2), ANOME VARCHAR2(45) NOT NULL, ADESC VARCHAR2(60), LOCALA VARCHAR2(5), SMIN NUMBER(8) CHECK( SMIN>0), SMAX NUMBER(9) NOT NULL, QA NUMBER(10) NOT NULL, TE NUMBER(3) NOT NULL, PRIMARY KEY(COD_GRUPO,COD_FAMILIA,COD_ARTIGO), FOREIGN KEY (COD_GRUPO, COD_FAMILIA) REFERENCES FAMILIA(COD_GRUPO,COD_FAMILIA), CONSTRAINT FK FOREIGN KEY (COD_GRUPO) REFERENCES GRUPO(COD_GRUPO));


Alterações de uma tabela Acrescentar colunas a uma tabela ALTER TABLE <nome da tabela> ADD (nome_coluna tipo(tamanho) [<restrições de integridade>], -----); Exemplo: ALTER TABLE GRUPO

ADD (TIPO CHAR(1) CHECK(TIPO=’S’ OR TIPO=’L’)); Acrescentar uma restrição a uma tabela ALTER TABLE <nome da tabela> ADD CONSTRAINT <nome-restrição>; Exemplo: ALTER TABLE GRUPO ADD CONSTRAINT TP FOREIGN KEY (TIPO) REFERENCES TAB_TIP(TIPO); Modificar o tipo de uma coluna ALTER TABLE <nome da tabela> MODIFY (nome-coluna novo_tipo(tamanho), .....); Exemplo: ALTER TABLE GRUPO

MODIFY (TIPO CHAR(2)); Eliminar uma restrição a uma tabela ALTER TABLE <nome da tabela> DROP CONSTRAINT <nome-restrição>; Exemplo: ALTER TABLE GRUPO

DROP CONSTRAINT TP;


Limitações Não se pode: • Alterar uma coluna que contenha valores nulos de NULL para NOT NULL; • Acrescentar uma nova coluna NOT NULL (a menos que a tabela esteja vazia) solução: Introduzir a coluna com NULL e introduzir valores para todos os registos. Mudar depois o campo para NOT NULL; • Diminuir a dimensão de uma coluna nem alterar o seu tipo, a menos que a tabela esteja vazia. Apagar uma tabela DROP TABLE <nome da tabela>; Exemplo: DROP TABLE GRUPO; Causa a perda de todos os dados inseridos na tabela; Só pode ser eliminada por quem a criou ou pelo administrador da base de dados. Inserir registos numa tabela INSERT INTO <nome de tabela> [(coluna1,coluna2,....)] VALUES (valor1, valor2,.....); ExemploS: INSERT INTO GRUPO VALUES (1,’Material de Escritório’, null); INSERT INTO GRUPO (GDESC, COD_GRUPO) VALUES (’Material de Escritório’,1); • Só se pode inserir um registo de cada vez; • Pode-se omitir a lista de nomes de colunas desde que se respeite a ordem das

colunas e não se omita nenhum valor. • Pode-se inserir apenas alguns campos do registo, ficando os restantes campos com

valores nulos.


Copiar registos de outra tabela INSERT INTO <nome de tabela> [(coluna1,coluna2,....)] SELECT (lista) FROM <tabela(s)> WHERE <condição>; O número de itens na lista SELECT tem de ser igual ao número de colunas referidas no comando INSERT e os domínios de colunas correspondentes devem ser compatíveis. Apagar registos DELETE FROM <nome da tabela> WHERE <condição>; Exemplo: DELETE FROM GRUPO WHERE COD_GRUPO=1; Se a cláusula WHERE for omitida todos os registos são apagados. Actualizar registos UPDATE <nome de tabela> SET coluna = (valor, expressão,...), coluna = (valor, expressão,...),.... WHERE <condição>; Exemplo: UPDATE ARTIGO SET COD_GRUPO = 1, COD_FAMILIA = 2 WHERE ANOME=‘caneta bic preta’; Se a cláusula WHERE for omitida todos os registos são actualizados Os valores a actualizar podem ser o resultado de subconsultas ou expressões.


Preservação da integridade dos dados Restrições de Integridade definidas - na criação das tabelas; - na alteração das tabelas. Restrições de integridade verificadas na execução de - INSERT; - UPDATE; - DELETE. Exemplo de restrições: CREATE TABLE GRUPO (COD_GRUPO NUMBER(2) PRIMARY KEY, GDESC VARCHAR2(25) NOT NULL); CREATE TABLE FAMILIA (COD_GRUPO NUMBER(2), COD_FAMILIA NUMBER(3), FDESC VARCHAR2(25) NOT NULL, PRIMARY KEY(COD_GRUPO,COD_FAMILIA), FOREIGN KEY (COD_GRUPO) REFERENCES GRUPO(COD_GRUPO)); CREATE TABLE ARTIGO (COD_GRUPO NUMBER(2), COD_FAMILIA NUMBER(3), COD_ARTIGO NUMBER(3), ANOME VARCHAR2(45) NOT NULL, SMIN NUMBER(8) CHECK( SMIN>0), PRIMARY KEY(COD_GRUPO,COD_FAMILIA,COD_ARTIGO), FOREIGN KEY (COD_GRUPO, COD_FAMILIA) REFERENCES FAMILIA(COD_GRUPO,COD_FAMILIA), CONSTRAINT FK FOREIGN KEY (COD_GRUPO) REFERENCES GRUPO(COD_GRUPO));


GRUPO COD_GRUPO GDESC 1 Material de Escritório 2 Material de Jardim FAMILIA COD_GRUPO COD_FAMILIA FDESC 1 1 lápis 1 2 caneta 1 3 folhas de papel 2 1 pá 2 2 balde ARTIGO COD_GRUPO COD_FAMILIA COD_ARTIGO ANOME SMIN 1 1 1 lápis de desenho vermelho 20 1 1 2 lápis normal 100 1 2 1 Caneta bic vermelha 50 1 2 2 Caneta bic azul 100 1 3 1 folhas A4 1000 1 3 2 folhas A3 1000 2 2 1 balde para água 3 Violação de restrições de integridade: exemplos; INSERT INTO ARTIGO VALUES (3,1,2,’livro’,100); Viola integridade referencial. COD_GRUPO = 3 não existe. INSERT INTO ARTIGO VALUES (1,1,1,’outro lápis’,100); Viola restrição de chave única. INSERT INTO GRUPO VALUES (3,null); Viola teste de integridade GDESC não pode ser nulo.


INSERT INTO ARTIGO VALUES (1,1,3,’livro’,-5); Viola teste de integridade SMIN>0. UPDATE FAMILIA SET COD_GRUPO=3 WHERE COD_FAMILIA=1; Viola integridade referencial. COD_GRUPO = 3 não existe. UPDATE FAMILIA SET COD_GRUPO=1 WHERE FDESC=‘pá’; Não viola integridade referencial. COD_GRUPO = 1 existe, mas viola a integridade de entidade. 1,1 já existe. DELETE FROM GRUPO WHERE COD_GRUPO=1; Viola integridade referencial. COD_GRUPO = 1 é referenciado por outras tabelas. Violação de integridade referencial Regras para a manipulação de dados na tabela de referência e as acções a desencadear sobre os dados dependentes.

- RESTRICT - Não é permitido actualizar ou apagar dados de referência; - SET TO NULL - Se os dados de referência são apagados todos os dados

dependentes ficam nulos. - SET TO DEFAULT - Se os dados de referência são apagados todos os dados

dependentes ficam com um valor por defeito. - CASCADE - quando os dados de referência são alterados todos os dados

dependentes são actualizados.


Apagamento em cascata (Exemplo) CREATE TABLE ARTIGO (COD_GRUPO NUMBER(2), COD_FAMILIA NUMBER(3), COD_ARTIGO NUMBER(3), ANOME VARCHAR2(45) NOT NULL, SMIN NUMBER(8) CHECK( SMIN>0), PRIMARY KEY(COD_GRUPO,COD_FAMILIA,COD_ARTIGO), FOREIGN KEY (COD_GRUPO, COD_FAMILIA) REFERENCES FAMILIA(COD_GRUPO,COD_FAMILIA) ON DELETE CASCADE, CONSTRAINT FK FOREIGN KEY (COD_GRUPO) REFERENCES GRUPO(COD_GRUPO) ON DELETE CASCADE); Integridade através de abordagem declarativa Vantagens: - Evita a necessidade de programas para garantir a integridade dos dados; - Definição simples e rápida; - Testes de integridade optimizados pelo SQL; - Regras centralizadas e controladas pelo SGBD; - É fácil alterar restrições sem mexer nas aplicações; - Flexibilidade em activar/desactivar restrições; Desvantagens: - A validação dos dados não é imediata (só é feita na execução do INSERT ou UPDATE. - Maior volume de comunicação entre o cliente e servidor.


Query (Consulta) - SELECT A instrução SELECT extrai informação da base de dados, implementando todos os operadores de Álgebra Relacional. Na sua forma mais simples, deve incluir: 1. uma clausula SELECT, que liste as colunas a visualizar. 2. uma clausula FROM, que especifica a tabela a que respeita. Exemplo: Para listar os nomes e descrição de todos os artigos da tabela ARTIGO: SELECT ANOME , ADESC FROM ARTIGO; ANOME ADESC --------------------------------------------------------------------------------------------------------- caneta bic preta caneta que escreve bem caneta bic vermelha caneta de correcções folhas de papel A4 Papel da impressora folhas de papel A3 Folhas maiores É possível seleccionar todas as colunas da tabela especificando um * (asterisco) a seguir à palavra de comando de SELECT. Exemplo: SELECT * FROM ARTIGO;


Expressões Aritméticas Uma expressão é uma combinação de valores, operadores e funções que produz uma valor. As expressões aritméticas podem conter nomes de colunas, valores numéricos constantes e os operadores aritméticos (+,-,*,/). (As regras de prioridade em expressões aritméticas são iguais às das linguagens de programação.) Exemplo: SELECT ANOME ,SMIN*2 FROM ARTIGO; ANOME SMIN*2 --------------------------------------------------------------------------------------------------------- caneta bic preta 1000 caneta bic vermelha 500 folhas de papel A4 400 folhas de papel A3 2000 Operador de concatenação O operador de concatenação (||) permite ligar colunas a outras colunas, a expressões aritméticas ou a valores constantes para criar uma expressão de caracteres. As colunas de ambos os lados do operador são combinadas de modo a constituir uma só coluna. Exemplo: Para combinar o nome e a descrição do ARTIGO: SELECT ANOME || ADESC FROM ARTIGO; ANOME||ADESC --------------------------------------------------------------------------------------------------------- caneta bic pretaCaneta que escreve bem caneta bic vermelhaCaneta de correcções folhas de papel A4Papel da impressora folhas de papel A3Folhas maiores


Literais Um literal é qualquer caracter, expressão ou número incluído na lista de SELECT que não seja um nome de coluna. Um literal na lista de SELECT é parte do resultado para cada um dos registos seleccionados. Sequências de caracteres em formato livre podem ser incluídas no resultado da consulta, e são tratados como uma coluna na lista do SELECT. Literais do tipo data ou caracter podem ser indicados entre plicas (‘); literais numéricos não necessitam de plicas. Exemplo: SELECT ANOME ||‘ - ’||ADESC, ‘ Artigos do armazém’ FROM ARTIGO; ANOME||’ - ‘||ADESC ‘Artigos do armazém’ --------------------------------------------------------------------------------------------------------- caneta bic preta - caneta que escreve bem Artigos do armazém caneta bic vermelha - caneta de correcções Artigos do armazém folhas de papel A4 - Papel da impressora Artigos do armazém folhas de papel A3 - Folhas maiores Artigos do armazém Tratamento de valores nulos Se um registo não contiver nenhum valor numa determinada coluna, esse valor diz_se NULL (NULO). Um valor nulo é um valor que não está disponível, não está atribuído, é desconhecido ou não é aplicável. Um valor nulo não é o mesmo que zero porque zero é um número. Os valores nulos ocupam um byte de memória interna de armazenamento. Se numa expressão, quaisquer valores da coluna forem nulos, o resultado é nulo. Exemplo: SELECT ANOME ,SMIN*2, SMAX FROM ARTIGO; ANOME SMIN*2 SMAX --------------------------------------------------------------------------------------------------------- caneta bic preta 1000 3000 caneta bic vermelha 500 folhas de papel A4 400 1000 folhas de papel A3 2000


Cláusula DISTINCT Para eliminar valores duplicados no resultado, inclui-se a cláusula DISTINCT Exemplo:

SELECT COD_FAMILIA FROM ARTIGO;

COD_FAMILIA --------------------------- 1 1 2 2 SELECT DISTINCT COD_FAMILIA FROM ARTIGO;

COD_FAMILIA ------------------------- 1 2 Cláusula ORDER BY Normalmente, a sequência dos registos produzidos no resultado de uma consulta não é definida. A cláusula ORDER BY pode ser utilizada para ordenar os registos. Se for utilizada, ORDER BY tem de ser a última cláusula na instrução SELECT. Exemplo (Para ordenar por nome de artigo):

SELECT ANOME , ADESC FROM ARTIGO ORDER BY ANOME;

ANOME ADESC --------------------------------------------------------------------------------------------------------- caneta bic preta caneta que escreve bem caneta bic vermelha caneta de correcções folhas de papel A3 Folhas maiores folhas de papel A4 Papel da impressora Exemplo (Também é possível ordenar por vária colunas):

SELECT COD_GRUPO , COD_FAMILIA FROM ARTIGO ORDER BY COD_GRUPO,COD_FAMILIA DESC;

COD_GRUPO COD_FAMILIA ------------------------------------------------------- 1 1 1 2 2 1 2 2 DESC – para ordem decrescente.


Clausula WHERE • A clausula WHERE corresponde ao operador de Restriction (Restrição) da

Álgebra Relacional. • Contém uma restrição que os registos têm que satisfazer para que sejam

visualizados. • A cláusula WHERE, se utilizada tem que seguir a cláusula FROM. • A cláusula WHERE pode comparar valores de colunas, valores literais, expressões

aritméticas ou funções. Tem 3 elementos: 1. O nome de um coluna; 2. Um operador de comparação (=,>,>=,<,<=); 3. O nome de uma coluna, uma constante ou lista de valores. Exemplo: SELECT ANOME ,SMIN, SMAX FROM ARTIGO; ANOME SMIN SMAX --------------------------------------------------------------------------------------------------------- caneta bic preta 500 3000 caneta bic vermelha 250 folhas de papel A4 200 1000 folhas de papel A3 1000 SELECT ANOME ,SMIN, SMAX FROM ARTIGO WHERE SMIN<500; ANOME SMIN SMAX --------------------------------------------------------------------------------------------------------- caneta bic vermelha 250 folhas de papel A4 200 1000 SELECT ANOME ,SMIN, SMAX FROM ARTIGO WHERE ANOME= ‘caneta bic preta’;

ANOME SMIN SMAX --------------------------------------------------------------------------------------------------------- caneta bic preta 500 3000


AND/OR podem ser utilizados numa cláusula WHERE para construir condições mais complexas. IS NULL/ IS NOT NULL - para verificar se os valores das colunas são nulos. Exemplo: SELECT ANOME ,SMIN, SMAX FROM ARTIGO WHERE SMIN>=200 AND SMAX IS NULL; ANOME SMIN SMAX --------------------------------------------------------------------------------------------------------- caneta bic vermelha 250 BETWEEN .. AND /NOT BETWEEN .. AND- procura registos com as colunas entre dois valores. SELECT ANOME ,SMIN, SMAX FROM ARTIGO WHERE SMIN BETWEEN 200 AND 500; ANOME SMIN SMAX --------------------------------------------------------------------------------------------------------- caneta bic preta 500 3000 caneta bic vermelha 250 folhas de papel A4 200 1000 IN/ NOT IN - Procura os valores numa lista específica. Exemplo: SELECT ANOME ,SMIN, SMAX FROM ARTIGO WHERE SMIN IN (500,1000); ANOME SMIN SMAX --------------------------------------------------------------------------------------------------------- caneta bic preta 500 3000 folhas de papel A3 1000


LIKE / NOT LIKE - para procurar uma cadeia de caracteres utilizando caracteres de substitição. % - representa uma sequência de caracteres com nenhum ou vários valores - - representa um só caractere. Exemplo: SELECT ANOME ,SMIN, SMAX FROM ARTIGO WHERE ANOME LIKE ‘c%’; ANOME SMIN SMAX --------------------------------------------------------------------------------------------------------- caneta bic preta 500 3000 caneta bic vermelha 250 Pseudónimos de colunas no comando SELECT Utilizam-se para alterar o cabeçalho da coluna. O pseudónimo é especificado a seguir à coluna no comando SELECT. Exemplo: SELECT ANOME NOME,SMIN “STOCK MÍNIMO”, SMAX “STOCK MÁXIMO” FROM ARTIGO WHERE SMIN<500; NOME STOCK MÍNIMO STOCK MÁXIMO --------------------------------------------------------------------------------------------------------- caneta bic vermelha 250 folhas de papel A4 200 1000


Álgebra Relacional - Operadores Relacionais Operadores Unários Operadores Binários • Restrição • União • Divisão • Projecção • Intersecção • Produto Cartesiano • Diferença • Junção Restrição Operação que permite seleccionar registo(s) de uma relação que satisfazem uma dada condição. Exemplos: SELECT * FROM ARTIGO WHERE SMIN<500; ANOME SMIN SMAX ....... --------------------------------------------------------------------------------------------------------- caneta bic vermelha 250 ....... folhas de papel A4 200 1000 ....... SELECT * FROM ARTIGO WHERE SMIN>=200 AND SMAX IS NULL; ANOME SMIN SMAX ....... --------------------------------------------------------------------------------------------------------- caneta bic vermelha 250 ....... Projecção Operação que permite seleccionar uma (ou mais colunas) de uma relação e criar uma nova relação. Exemplo: SELECT ANOME ,SMIN, SMAX FROM ARTIGO; ANOME SMIN SMAX --------------------------------------------------------------------------------------------------------- caneta bic preta 500 3000 caneta bic vermelha 250 folhas de papel A4 200 1000 folhas de papel A3 1000


Restrição e Projecção Pode-se combinar as operações de restrição e projecção. Exemplo: SELECT ANOME ,SMIN, SMAX FROM ARTIGO WHERE SMIN IN (500,1000); ANOME SMIN SMAX --------------------------------------------------------------------------------------------------------- caneta bic preta 500 3000 folhas de papel A3 1000 União A união de duas relações resulta numa nova relação que contém todos os tuplos existentes em ambas as relações. Exemplo: GRUPO COD_GRUPO GDESC 1 Material de Escritório 2 Material de Jardim GRUPO_TAB COD_GRUPO GDESC 3 Material Reprografia 4 Material Cantina SELECT * FROM GRUPO UNION SELECT * FROM GRUPO_TAB; COD_GRUPO GDESC --------------------------------------------------------------------------------------------------------- 1 Material de Escritório 2 Material de Jardim 3 Material Reprografia 4 Material Cantina Compatibilidade em União • Ambas as relações têm que ter o mesmo grau (mesmo número de colunas); • Colunas correspondentes em cada relação têm que ter o mesmo domínio. Muitas vezes as uniões são feitas sobre a mesma tabela, de modo a combinar os resultados de duas ou mais instruções SELECT. Intersecção


A intersecção de duas relações produz uma nova relação com os registos que pertencem simultaneamente a ambas as relações. As relações têm de ser compatíveis em união. Exemplo: GRUPO COD_GRUPO GDESC 1 Material de Escritório 2 Material de Jardim 3 Material Reprografia GRUPO_TAB COD_GRUPO GDESC 1 Material de Escritório 3 Material Reprografia 4 Material Cantina SELECT * FROM GRUPO INTERSECT SELECT * FROM GRUPO_TAB; COD_GRUPO GDESC --------------------------------------------------------------------------------------------------------- 1 Material de Escritório 3 Material Reprografia


Diferença A diferença entre duas relações produz uma nova relação com os registos que pertencem à primeira relação mas não pertencem à segunda. As relações têm de ser compatíveis em união. Exemplo: GRUPO COD_GRUPO GDESC 1 Material de Escritório 2 Material de Jardim 3 Material Reprografia GRUPO_TAB COD_GRUPO GDESC 1 Material de Escritório 4 Material Cantina SELECT * FROM GRUPO MINUS SELECT * FROM GRUPO_TAB; COD_GRUPO GDESC --------------------------------------------------------------------------------------------------------- 2 Material de Jardim 3 Material Reprografia


Produto Cartesiano O produto cartesiano de duas relações R1 e R2 é uma nova relação R3 na qual cada tuplo de R1 é adicionado a todos os tuplos de R2. GRUPO COD_GRUPO GDESC 1 Material de Escritório 2 Material de Jardim FAMILIA COD_FAMILIA FDESC 1 lápis 2 caneta 3 folhas de papel 1 pá 2 balde SELECT * FROM GRUPO, FAMILIA; COD_FAMILIA FDESC COD_GRUPO GDESC --------------------------------------------------------------------------------------------------------- 1 lápis 1 Material de Escritório 2 caneta 1 Material de Escritório 3 folhas de papel 1 Material de Escritório 1 pá 1 Material de Escritório 2 balde 1 Material de Escritório 1 lápis 2 Material de Jardim 2 caneta 2 Material de Jardim 3 folhas de papel 2 Material de Jardim 1 pá 2 Material de Jardim 2 balde 2 Material de Jardim O resultado do produto cartesiano é de utilidade muito limitada uma vez que os registos são associados sem qualquer critério.


Equi-junção Juntar os dados de duas relações através de restrições. GRUPO COD_GRUPO GDESC 1 Material de Escritório 2 Material de Jardim FAMILIA COD_G COD_FAMILIA FDESC 1 1 lápis 1 2 caneta 1 3 folhas de papel 2 1 pá 2 2 balde SELECT * FROM FAMILIA, GRUPO WHERE COD_G=COD_GRUPO; COD_G COD_FAMILIA FDESC COD_GRUPO GDESC --------------------------------------------------------------------------------------------------------- 1 1 lápis 1 Material de Escritório 1 2 caneta 1 Material de Escritório 1 3 folhas de papel 1 Material de Escritório 2 1 pá 2 Material de Jardim 2 2 balde 2 Material de Jardim


Equi-Junção, projecção e restrição Vulgarmente a equi-junção usa-se em conjunto com a projecção e/ou restrição, de modo a eliminar colunas/registos desnecessários para o resultado (junção natural). Exemplo: SELECT COD_GRUPO,COD_FAMILIA, FDESC FROM FAMILIA, GRUPO WHERE COD_G=COD_GRUPO AND COD_G=1; COD_G COD_FAMILIA FDESC ---------------------------------------------------------- 1 1 lápis 1 2 caneta 1 3 folhas de papel Distinguir colunas com o mesmo nome em tabelas diferentes GRUPO COD_GRUPO GDESC 1 Material de Escritório 2 Material de Jardim FAMILIA COD_GRUPO COD_FAMILIA FDESC 1 1 lápis 1 2 caneta 1 3 folhas de papel 2 1 pá 2 2 balde SELECT F.COD_GRUPO, COD_FAMILIA, GDESC FROM FAMILIA F, GRUPO G WHERE F.COD_GRUPO=G.COD_GRUPO; COD_GRUPO COD_FAMILIA GDESC ----------------------------------------------------------------------------------------- 1 1 Material de Escritório 1 2 Material de Escritório 1 3 Material de Escritório 2 1 Material de Jardim 2 2 Material de Jardim


Não equi-junção NOTAS N_aluno Disciplina Nota 12345 Português 12 12348 Inglês 16 12345 História 18 12349 Inglês 12 ESCALA Nota_min Nota_max Classif 0 9 Reprovado 10 13 Suficiente 14 15 Bom 16 17 Bom c. Distinção 18 20 Excelente SELECT N_ALUNO, DISCIPLINA,CLASSIF FROM NOTAS, ESCALA WHERE N_ALUNO=12345 AND NOTA BETWEEN NOTA_MIN AND NOTA_MAX; N_ALUNO DISCIPLINA CLASSIF ----------------------------------------------------------------------------------------- 12345 Português Suficiente 12345 História Excelente


Junção Externa (+) Se se pretender fazer a junção das tabelas Grupo e Família, independentemente do facto de alguns grupos não terem famílias, é necessário uma junção externa. GRUPO COD_GRUPO GDESC 1 Material de Escritório 2 Material de Jardim 3 Material Reprografia 4 Material Cantina FAMILIA COD_GRUPO COD_FAMILIA FDESC 1 1 lápis 1 2 caneta 1 3 folhas de papel 2 1 pá 2 2 balde

COD_GRUPO COD_FAMILIA FDESC GDESC 1 1 lápis Material de Escritório 1 2 caneta Material de Escritório 1 3 folhas de papel Material de Escritório 2 1 pá Material de Jardim 2 2 balde Material de Jardim 3 NULL NULL Material Reprografia 4 NULL NULL Material Cantina

1º Tabela Principal 2º Tabela Secundária Podem existir registos nesta tabela que não representados na tabela principal (nulos).

SELECT G.COD_GRUPO, COD_FAMILIA, FDESC, GDESC FROM GRUPO G, FAMILIA F WHERE F.COD_GRUPO (+) =G.COD_GRUPO;


Funções de SQL

Funções de manipulação de caracteres LOWER(col|valor) Força para minúsculas os valores alfanuméricos do tipo caracter que estejam em maiúsculas. UPPER(col|valor) Força para maiúsculas os valores alfanuméricos do tipo caracter que estejam em minúsculas. INTCAP(col|valor) Força uma maiúscula na primeira letra de cada palavra. LPAD(col|valor,n,’cadeia’) preenche a coluna ou o valor literal a partir da esquerda, até um total de n posições de caracteres. Se for omitido o valor, é preenchido com espaços.

Ex. LPAD(DNAME,20,’*’) ------------------------------------- ************RESEARCH *****************SALES

RPAD(col|valor,n,’cadeia’) preenche a coluna ou o valor literal a partir da direita, até um total de n posições de caracteres. Se for omitido o valor, é preenchido com espaços.

Ex. RPAD(DNAME,20,’*’) -------------------------------------- RESEARCH************ SALES*****************

SUBSTR(col|valor, pos,n) produz uma cadeia de n caracteres de tipo longo da coluna ou valor de literal, começando na posição número pos. Se n for omitido, a cadeia é extraída desde pos n até ao fim.

Ex. SUBSTR(‘FONSECA’,2,3) -------------------------------------- ONS


INSTR(col|valor, ’cadeia’) localiza a posição da primeira ocorrência de ’cadeia’. Ex. INSTR(‘FONSECA’,’N’) -------------------------------------- 3

INSTR(col|valor, ’cadeia’, pos,n) localiza a posição da n-ésima ocorrência de ’cadeia’ a partir da posição pos. LTRIM(col|valor, ’caracteres’) retira as ocorrências do caracter (ou combinação de caracteres) especificados que precedam à esquerda dos outros caracteres. Se caracteres não for especificado, serão retirados todos os espaços em branco à esquerda. RTRIM(col|valor, ’caracteres’) retira as ocorrências do caracter (ou combinação de caracteres) especificados que precedam à direita dos outros caracteres. Se caracteres não for especificado, serão retirados todos os espaços em branco à direita. LENGTH(col|valor) produz o número de caracteres (ou dígitos) na coluna ou no valor do literal. TRANSLATE(col|valor, de, para) substitui o caracter de (de) pelo caracter de (para). Será efectuada a substituição em todas as ocorrências.

Ex. TRANSLATE(‘FONSECA’,’S’,’T’) -------------------------------------- FONTECA

REPLACE(col|valor, de, para) substitui a cadeia de caracteres de (de) pela cadeia de caracteres de (para). Será efectuada a substituição em todas as ocorrências.


Funções Numéricas ROUND(col|valor, n) arredonda para n casas decimais. Se n for omitido, arredonda para unidades. Se n for negativo, são arredondados dígitos à esquerda do separador decimal. CEIL(col|valor) determina o menor inteiro maior ou igual que o valor da coluna, a expressão ou valor.

Ex. CEIL(99.9) 100 CEIL(101.26) 102 CEIL(-11.1) -11

FLOOR(col|valor) determina o maior inteiro menor ou igual que o valor da coluna, a expressão ou valor.

Ex. FLOOR(99.9) 99 FLOOR (101.26) 101 FLOOR (-11.1) -12

POWER(col|valor, n) eleva à potência de n (n deve ser um número inteiro). SQRT(col|valor) determina a raiz quadrada. SIGN(col|valor) dá como resultado –1 se a coluna, valor ou expressão for negativo, 0 se for zero e +1 se for positivo. (Utiliza-se para comparar dois valores Ex. SIGN(x-y)). ABS(col|valor) determina o valor absoluto. MOD(valor1, valor2) determina o resto da divisão de valor1 por valor2.


Funções de manipulação de datas Para visualizar a data actual: SELECT SYSDATE FROM SYS.DUAL; Operadores aritméticos Data+número adiciona um número de dias à data, produzindo uma data. Data-número subtrai um número de dias à data, produzindo uma data. Data-data subtrai uma data de outra data, produzindo um número de dias. Data+número/24 adiciona um número de horas à data, produzindo uma data. MONTHS_BETWEEN(data1,data2) número de meses entre data1 e data2. ADD_MONTHS(data1, n) adiciona n meses de calendário à data1. NEXT_DAY(data1, car) data do próximo dia da semana especificado. LAST_DAY(data1) último dia do mês da data1. ROUND(data1) produz a data1 com hora 12AM (meio dia). ROUND(data1, ‘MONTH’) arredonda a data ao mês (produzindo o

primeiro dia do mês). ROUND(data1, ‘YEAR’) arredonda a data ao ano (produzindo o

primeiro dia do ano). TRUNC(data1, ‘MONTH’) encontra a data do primeiro dia do mês que

contém data1. TRUNC(data1, ‘YEAR’) encontra a data do primeiro dia do ano que

contém data1. Funções de Conversão TO_CHAR(número|data, [‘fmt’]) converte número ou data para caracteres com o

formato ‘fmt’. TO_NUMBER(car) converte caracteres para um valor numérico. TO_DATE(‘car’, ‘fmt’) converte o valor car, representando uma data,

para um valor do tipo data no formato fmt especificado.


Formatos de Data Formato Significado SCC ou CC Século; 'S' faz preceder de '-' uma data "BC" (AC). YYYY ou SYYYY Ano; 'S' faz preceder de '-' uma data 'BC' (AC). YYY ou YY ou Y Último(s) 3, 2 ou 1 dígito(s) do ano. Y,YYY Ano, com a vírgula nesta posição. SYEAR ou YEAR Ano, por extenso; 'S' faz preceder de '-' uma data 'BC' (AC). BC (AC) ou AD (DC) Indicador BC/AD (AC/DC). B.C. ou A.D. Indicador BC/AD (AC/ DC) com pontos. Q Trimestre do ano. MM MÊS. MONTH Nome do mês, preenchido com espaços até um comprimento de 9

caracteres. MON Nome do mês: abreviatura de 3 letras. WW ou W Semana do ano ou do mês. DDD ou DD ou D Dia do ano, do mês ou da semana. DAY Nome do dia, preenchimento com espaços até um comprimento de

9 caracteres. DY Nome do dia; abreviatura de 3 letras. J Dia Juliano; o número de dias desde 31 Dezembro 4713 A.C. AM ou PM Indicador de meridiano. A.M. ou P.M. Indicador de meridiano com pontos. HH ou HH12 Hora do dia (1-12). HH24 Hora do dia (0-23). MI Minutos. SS Se g u n d o s. SSSSS Segundos desde a meia-noite (0-86399). /...etc. A pontuação é reproduzido no resultado. “...” Uma cadeia de caracteres entre aspas é reproduzida no resultado. O seguinte prefixo pode ser acrescentado aos códigos acima indicados: fm 'Fill Mode'. Como prefixo de MONTH ou DAY, suprime o preenchimento a

espaços, dando um resultado de comprimento variável FM irá suprimir os zeros à esquerda no formato ddth. Não é significativo com os outros códigos. Uma segunda ocorrência de 'fm' torna activo o preenchimento a espaços.


Os códigos são sensíveis a maiúsculas/ minúsculas e irão afectar a visualização dos elementos da data: DAY MONDAY Day Monday Month July ddth 14th ddTh 14Th Formatos de Números Elemento Significado Exemplo 9 posição numérica(o número de 9s determina

a largura da apresentação) 999999 1234

0 zeros antes do n ú mero 099999 001234

$ símbolo do dólar $999999 $1234 . ponto decimal na posição especificada 999999.99 1234.00 , vírgula na posição especificada 999,999 1,234 M I sinal menos à direita (valores negativos) 999999MI 1234- PR coloca nºs negativos entre parêntesis 999999 <l234 > EEEE notação científica (o formato deve conter

apenas 4 Es.) 99.999EEEE 1.234E+03

V multiplicar por 10n (n =nº de 9s depois de V)

9999V99 123400

B apresentar valores nulos como espaço em branco, não como 0

B9999.99 1234.00


Inserir Informação de Data e Hora Utilizar a função TO_DATE para simplificar a introdução. Exemplo: INSERT INTO EMP (EMPNO, ENAME, JOB, MGR, HIREDATE, SAL, COMM, DEPTNO) VALUES (7658, ‘JOÃO’, ‘ANALYST’, 7566, TO_DATE(2001/07/01 9:30’, ‘YYYY/MM/DD HH:MI’), 3000, NULL, 20); Funções que aceitam qualquer tipo de dados como argumento DECODE Facilita consultas condicionais permitindo fazer o mesmo que um comando ‘case’ ou ‘if-then-else’ das linguagens de programação tradicionais. NVL( col|valor, val) converte um valor NULL em val. GREATEST( col|valor1, col|valor2,...) produz o maior de uma lista de valores. LOWEST( col|valor1, col|valor2,...) produz o menor de uma lista de valores. VSIZE(col|valor) produz o número de bytes ocupados pela representação interna do ORACLE.


DECODE Facilita consultas condicionais permitindo fazer o mesmo que um comando 'case' ou 'if-then-else' das linguagens de programação tradicionais ais: Sintaxe: DECODE (col/expressão, pesquisa1, resultado1, [pesquisa2, resultado2, ...] valor por omissão) Col/expressão é comparada com cada valor pesquisa e produz o resultado se col/expressão for igual ao valor a pesquisar. Se não for encontrada nenhuma correspondência, a função DECODE produz o valor por omissão. Se o valor por omissão for omitido, será produzido um valor NULL (NULO) para os valores sem correspondência. Argumentos DECODE tem de ter um mínimo de 4 parâmetros ou argumentos. • COL/EXPRESSÃO - o nome da coluna ou da expressão a ser avaliada. • PESQUISA1 - o primeiro valor a verificar. • RESULTADO1 - o valor a ser produzido se existir correspondência com

pesquisa1. • PESQUISA1 e RESULTADO1 podem ser repetidos tantas vezes quantas as

necessárias – [PESQUISA2, RESULTADO2, PESQUISA3, RESULTADO3 .... ] • VA LOR POR OMISSÃO - o valor a ser produzido se não houver nenhuma

correspondência. • Col/expressão podem ser de qualquer tipo de dados. • PESQUISA deve ser do mesmo tipo de dados que col/expressão. • O valor produzido é forçado para o mesmo tipo de dados que o terceira argumento

(resultado1).


O exemplo seguinte descodifica apenas os tipos de função MANAGER e CLERK nenhum dos outros será verificado pelo que serão o valor por omissão INDEFINIDO. SELECT ENAME, JOB, DECODE (JOB, ‘CLERK’,’TRABALHADOR’, ‘MANAGER’, ‘CHEFE’, ‘INDEFINIDO’) JOB_DESCODIFICADO FROM EMP; ENAME JOB JOB_DESCODIF SMITH CLERK TRABALHADOR ALLEN SALESMAN NÃO_DEFINIDO WARD SALESMAN NÃO_DEFINIDO JONES MANAGER CHEFE MARTIN SALESMAN NÃO_DEFINIDO BLAKE MANAGER CHEFE CLARK MANAGER CHEFE SCOTT ANALYST NÃO_DEFINIDO KING PRESIDENT NÃO_DEFINIDO TURNER SALESMAN NÃO_DEFINIDO ADAMS CLERK TRABALHADOR JAMES CLERK TRABALHADOR FORD ANALYST NÃO_DEFINIDO MILLER CLERK TRABALHADOR Para visualizar as percentagens de bónus dependentes do escalão salarial, digite: SELECT GRADE, DECODE (GRADE, '1’, ‘15%’, ‘2’ , ‘10%’, ‘3’ , ‘8%’, ‘5%’) BONUS FROM SALGRADE; GRADE BONUS --------------------------------- 1 15% 2 10% 3 8% 4 5% 5 5%


Funções de Grupo AVG(n) valor médio de n, ignorando valores nulos. COUNT(n *) número de vezes n toma um valor não nulo. MAX(n) valor máximo de n. MIN(n) valor mínimo de n. STDDEV(n) desvio padrão de n, ignorando valores nulos. SUM(n) soma de n, ignorando valores nulos. VARIANCE(n) variância de n, ignorando valores nulos. Ex.

Para determinar o salário médio dos empregados: SELECT AVG(SAL) FROM EMP; Para determinar o número de empregados do departamento 20: SELECT COUNT(*) FROM EMP WHERE DEPTNO=20;

A cláusula GROUP BY Pode ser utilizada para dividir os registos de uma tabela em grupos mais pequenos.

Ex. Para calcular o salário médio para cada função: SELECT JOB,AVG(SAL) FROM EMP GROUP BY JOB; Para apresentar o salário médio para cada função dentro de cada departamento: SELECT DEPTNO,JOB,AVG(SAL) FROM EMP GROUP BY DEPTNO, JOB;

A cláusula HAVING Pode ser utilizada para especificar quais os grupos que devem ser visualizados.

Ex. Para mostrar apenas as funções cujo salário é maior ou igual a $3000:

SELECT JOB,MAX(SAL) FROM EMP HAVING MAX(SAL)>=3000 GROUP BY JOB;


Subconsultas Encadeadas Uma subconsulta é uma instrução SELECT que está encadeada noutra instrução de SELECT e que produz resultados intermédios. SELECT coluna1, coluna2, ... FROM tabela WHERE coluna = (SELECT coluna1, coluna2, ... FROM tabela

WHERE condição); Exemplo: Para encontrar todos os empregados que tenham a mesma função que o Blake: SELECT ENAME, JOB FROM EMP WHERE JOB= (SELECT JOB FROM EMP WHERE ENAME=’BLAKE’); Também podem existir subconsultas a produzir mais de um registo. Exemplo: Para encontrar os empregados que ganham o menor salário em cada departamento: SELECT ENAME, SAL, DEPTNO FROM EMP WHERE SAL IN (SELECT MIN(SAL) FROM EMP GROUP BY DEPTNO); ANY – compara um valor com cada valor produzido por uma subconsulta. Exemplo: Para encontrar os empregados que ganham mais do que o salário mais baixo do departamento 30: SELECT ENAME, SAL, DEPTNO FROM EMP WHERE SAL > ANY (SELECT DISTINCT SAL FROM EMP WHERE DEPTNO=30) ORDER BY SAL DESC; ALL – compara um valor com qualquer dos valores produzidos pela subconsulta.

Exemplo: Para encontrar os empregados que ganham mais do que qualquer dos empregados do departamento 30: SELECT ENAME, SAL, DEPTNO FROM EMP WHERE SAL > ALL (SELECT DISTINCT SAL FROM EMP WHERE DEPTNO=30) ORDER BY SAL DESC;


Efectuar consultas com variáveis de substituição Estas variáveis são úteis quando utilizadas em ficheiros do tipo SQL, que são posteriormente executados através do comando START. Variáveis de substituição com um só ‘&’ As variáveis de substituição representam valores a serem dados no momento de execução. A variável é precedida por ‘&’ e é-lhe atribuído um valor. Exemplo: Para solicitar ao utilizador um valor para o stock mínimo: SELECT ANOME ,SMIN, SMAX FROM ARTIGO WHERE SMIN<&STOCK_MIN; Enter value for stock_min: 500 ANOME SMIN SMAX --------------------------------------------------------------------------------------------------------- caneta bic vermelha 250 folhas de papel A4 200 1000 O exemplo acima indicado utiliza a condição WHERE SMIN<500 Os valores do tipo caracter ou data têm de ser indicados entre plicas quando solicitados. Para evitar a introdução das plicas no tempo de execução, coloca-se a variável entre plicas. Exemplo: Para solicitar ao utilizador um valor o nome do artigo: SELECT ANOME ,SMIN, SMAX FROM ARTIGO WHERE ANOME=’&NOME_ARTIGO’; Enter value for nome_artigo: caneta bic preta ANOME SMIN SMAX --------------------------------------------------------------------------------------------------------- caneta bic preta 500 3000


É possível solicitar o nome de uma coluna ou de uma tabela no tempo de execução. Exemplo: Para solicitar ao utilizador um valor de uma expressão aritmética: SELECT ANOME , &EXP_ARITMETICA, SMAX FROM ARTIGO; Enter value for exp_aritmetica: SMIN*2 ANOME SMIN*2 SMAX --------------------------------------------------------------------------------------------------------- caneta bic preta 1000 3000 caneta bic vermelha 500 folhas de papel A4 400 1000 folhas de papel A3 2000 Variáveis de substituição com dois ‘&’ Se a variável de substituição for precedida por dois ‘&’ (&&), o SQL*Plus só pedirá o valor uma única vez. A variável fica definida a nível de sistema e é de novo utilizada sempre que a instrução SQL for executada. Exemplo: SELECT ANOME ,SMIN, SMAX FROM ARTIGO WHERE SMIN<&&STOCK_MIN; Enter value for stock_min: 500 ANOME SMIN SMAX --------------------------------------------------------------------------------------------------------- caneta bic vermelha 250 folhas de papel A4 200 1000


Comando DEFINE Este comando determina se uma variável já está definida. Exemplo: SQL> DEFINE DEFINE STOCK_MIN = “500” (CHAR) O comando DEFINE também pode ser utilizado para definir o valor de uma variável. O comando UNDEFINE limpa o valor da variável. Exemplo: SQL> DEFINE EXP_ARITMETICA = SMIN*2 SQL> SELECT ANOME , &&EXP_ARITMETICA, SMAX FROM ARTIGO; ANOME SMIN*2 SMAX --------------------------------------------------------------------------------------------------------- caneta bic preta 1000 3000 caneta bic vermelha 500 folhas de papel A4 400 1000 folhas de papel A3 2000 SQL> UNDEFINE EXP_ARITMETICA Comando ACCEPT Este comando permite criar uma variável e armazenar nela um valor que é introduzido no momento da execução. Vantagens: O tipo de dados pode ser verificado; Os indicadores (“prompts”) podem ser mais explícitos; Os valores das respostas podem ser ocultados. Sintaxe: ACC[EPT] variável [NUMBER|CHAR] [PROMPT|NOPROMPT ‘texto’] [HIDE] NUMBER|CHAR determina o tipo de variável; PROMPT ‘texto’ apresenta o texto especificado; NOPROMPT faz o ACCEPT saltar uma linha esperando pela introdução do valor; HIDE não apresenta a resposta do utilizador.


Exemplos (ACCEPT): SQL> ACCEPT SALARIO NUMBER PROMPT ‘Valor de Salário: ‘ Valor de Salário: 50000 SQL> ACCEPT PASSWORD CHAR PROMPT ‘Password: ‘ HIDE Password: SQL> ACCEPT C NUMBER NOPROMPT 500 SQL> DEFINE DEFINE SALARIO = 50000 (NUMBER) DEFINE PASSWORD = ‘AAA’ (CHAR) DEFINE C = 500 (NUMBER)


Vistas As vistas têm por objectivo de simplificar as consultas de dados que envolvem várias tabelas. Além disso, restringem o acesso à base de dados mostrando apenas parte dos dados de uma ou mais tabelas. Uma consulta sobre a vista é mais simples que uma consulta às várias tabelas que estão incluídas na vista. As vistas permitem ainda que os dados sejam visualizados de formas diferentes por diferentes utilizadores. CREATE VIEW <nome da vista> [(coluna1, coluna2,...)] AS SELECT ....... [WITH CHECK OPTION [CONSTRAINT nome_restrição]] Depois de criada a vista pode ser usada como se fosse uma tabela. Vistas Simples: Derivam só de uma tabela e não contêm funções nem grupos de dados. Exemplo: CREATE VIEW VARTIGO (NOME_ART, STOCK_MIN, STOCK_MAX) AS SELECT ANOME ,SMIN, SMAX FROM ARTIGO WHERE SMIN=500; Vistas Complexas: Derivam de várias tabelas e contêm funções ou grupos de dados. Exemplo: CREATE VIEW QUANTS (COD_GRUPO,COD_FAMILIA,COD_ARTIGO, QT) AS SELECT A.COD_GRUPO, A.COD_FAMILIA, A.COD_ARTIGO, SUM(AQ.QT_INICIAL-AQ.QT_SAIDA) FROM AQ_LOTE AQ, ARTIGO A WHERE A.COD_ARTIGO=AQ.COD_ARTIGO AND A.COD_GRUPO=AQ.COD_GRUPO AND A.COD_FAMILIA=AQ.COD_FAMILIA GROUP BY A.COD_GRUPO,A.COD_FAMILIA,A.COD_ARTIGO


Utilizar vistas em operações DML - As vistas permitem executar verificações de integridade sobre os dados modificados através das vistas. - WITH CHECK OPTION indica que os INSERTs e UPDATEs executados através da vista só podem afectar registos seleccionáveis pela vista (definidos no WHERE). Exemplo: CREATE VIEW VARTIGO (NOME_ART, STOCK_MIN, STOCK_MAX) AS SELECT ANOME ,SMIN, SMAX FROM ARTIGO WHERE SMIN=500 WITH CHECK OPTION; Apenas os registos em que SMIN é 500 podem ser objectos de inserções, actualizações ou apagamentos. Tratamento de vistas pelo SGBD O comando CREATE não leva à execução do SELECT a ele associado; este é apenas armazenado no dicionário de dados; Ao aceder a dados através de uma vista o sistema faz: - Extrai a definição da vista do dicionário de dados; - Verifica privilégios de acesso; - Converte a operação sobre a vista numa operação equivalente na tabela ou tabelas

da base de dados. Alterar dados através de vistas: limitações ao apagamento O comando DELETE não é permitido se a vista incluir - Condições de Junção; - Funções de Grupo; - Clausula GROUP BY; - O comando DISTINCT; - Subconsultas correlacionadas. Eliminar uma vista DROP VIEW <nome de vista> - O comando elimina apenas a definição da vista; os registos da(s) tabela(s) base não são afectados. - Se existirem outras vistas que dependem da vista eliminada estas deixam de ser válidas.


Sequências Utiliza-se o gerador de sequências para gerar automaticamente números de sequências para os registos das tabelas. Por exemplo, pode-se utilizar o gerador de sequências para produzir chaves primárias únicas. CREATE SEQUENCE nome_sequência [increment by n] [start with n] [maxvalue n | nomaxvalue] [minvalue n | nominvalue] INCREMENT BY Incrementado de (valor por omissão =1) START WITH valor inicial (valor por omissão =1) MAXVALUE | NOMAXVALUE valor máximo | nenhum valor máximo

(valor por omissão = 1 para sequências descendentes e 10e27-1 para sequências ascendentes)

MINVALUE | NOMINVALUE valor máximo | nenhum valor máximo (valor por omissão =1 para sequências ascendentes e 10e27-1 para sequências descendentes)

Exemplo: CREATE SEQUENCE N_GRUPO INCREMENT BY 10 START WITH 10 MAXVALUE 100000; Gerar números de sequência com NEXTVAL A pseudo-coluna NEXTVAL é utilizada para extrair de uma sequência especificada números de sequência sucessivos (através da vista do SYS.DUAL). Exemplo: SELECT N_GRUPO.NEXTVAL FROM SYS.DUAL; NEXTVAL --------------- 10 Se executar de novo a instrução: SELECT N_GRUPO.NEXTVAL FROM SYS.DUAL; NEXTVAL --------------- 20 Se referenciar várias vezes NEXTVAL na mesma instrução de SQL, cada referência produzirá o mesmo valor.


Para produzir valores únicos para a chave primária utilizar a sequência com o comando INSERT. Exemplo: INSERT INTO GRUPO VALUES (N_GRUPO.NEXTVAL,’Material de Escritório’, null); Utilizar números de sequência com CURRVAL Referencia o número de sequência actual. Exemplo: INSERT INTO GRUPO VALUES (N_GRUPO.CURRVAL,’Material de Escritório, null); Restrições relativas ao NEXTVAL e CURRVAL Não podem ser utilizados: - Dentro da lista de SELECT de uma vista; - Com DISTINCT; - Com ORDER BY, GROUP BY, CONNECT BY ou HAVING; - Com UNION, INTERSECT ou MINUS; - Dentro de uma subconsulta. Alterar uma sequência ALTER SEQUENCE nome_sequência [increment by n] [maxvalue n | nomaxvalue] [minvalue n | nominvalue] - Só afecta futuros números de sequência; - É efectuada uma validação. Por exemplo, não pode ser imposto um novo

MAXVALUE que seja inferior ao número actual da sequência. - Para recomeçar uma sequência com um novo valor inicial, a sequência deve ser

criada e criada de novo. Apagar uma sequência DROP SEQUENCE nome_sequência Como Produzir sequências sem usar o objecto sequence


Encontrar o valor máximo da coluna e somar 1. Exemplo; Select Max(empno)+1 from empr; triggers Um trigger é um programa em SQL sempre associado a uma tabela e dispara sempre que for executada a acção ( inserção, eliminação ou alteração a registos). triggers de linha - é activado sempre que a tabela é modificada pelo comando que activa o trigger. Por exemplo, se um trigger de linha é activado por um delete que elimina dez linhas na tabela, então o trigger será executado dez vezes. triggers de comando - executa apenas uma vez, independentemente do número de linhas afectadas pelo comando que activa o trigger. Um trigger pode ser definido para disparar antes ou depois do comando que o activa. Os triggers podem evocar procedimentos que também são objectos criados na base de dados. Procedimentos Procedimentos em PL/SQL podem ser guardados na base de dados e são também considerados objectos da base de dados. PL/SQL – linguagem procedimental que permite também utilizar comandos em SQL. (muito similar ao Pascal).


Exemplo (Trigger em PL/SQL que utiliza também um procedimento) CREATE PROCEDURE PAUD (T IN NUMBER, C IN CHAR,TP IN CHAR) AS US NUMBER(3); CP NUMBER(1); BEGIN SELECT UID INTO US FROM DUAL; SELECT ULT_APLICA INTO CP FROM UTILIZA WHERE COD_UTILIZA=US; INSERT INTO AUDITA (NUM_OPER,COD_APLICA,COD_UTILIZA,COD_TABELA,CHAVE,DATA,TIP_OP) VALUES (AUDS.NEXTVAL,CP,US,T,RTRIM(LTRIM(C)),SYSDATE,TP); END; CREATE TRIGGER TGRUPO AFTER UPDATE OF GDESC OR INSERT OR DELETE ON GRUPO FOR EACH ROW DECLARE CHAV CHAR(20); CG NUMBER(2); TAB NUMBER(3); CC CHAR(100); TP CHAR(1); BEGIN IF INSERTING THEN TP:='I'; END IF; IF DELETING THEN TP:='E'; END IF; IF UPDATING THEN TP:='A'; END IF; TAB:=1; CG:=:NEW.COD_GRUPO; CC:=RTRIM(LTRIM(TO_CHAR(CG,'09'))); CHAV:=RTRIM(LTRIM(CC)); PAUD(TAB,CHAV,TP); END;


V. Gestão de privacidade/segurança na base de dados Se o sistema de privacidade não for bem elaborado, corre-se o perigo de existirem intrusos à base de dados. Intruso • Utilizador ou pessoa desconhecida que destrói dados relevantes, através de

eliminações, inserções ou alterações a objectos da base de dados; • Intrusos que desejam consultar informação confidencial existente na base de dados; • Existem os seguintes motivos para fraude não deliberada: A ignorância sobre o

sistema, a incompetência, a falta de cuidado, a má verificação na entrada de dados, o treino inadequado etc.

• As fraudes de motivação deliberada visam proveitos materiais, brincadeiras, desafios ou simplesmente curiosidade, muitas vezes sem intenção de danificar dados ou ter acesso a informação sigilosa.

Como montar o sistema de segurança • Minimizar ao máximo a vulnerabilidade do sistema de base de dados; • O desenhador identifica os perfiles de utilizadores da base de dados. (utilizadores

com responsabilidades que variam) Montar um sistema de privacidade que só deixe cada utilizador aceder aos objectos da base de dados que lhe são necessários para cumprir as suas responsabilidades.

Privilégios O direito de um utilizador aceder a um objecto de outro utilizador ou de executar um determinado comando em SQL. Privilégios do sistema • Determinam o tipo de acções que o utilizador pode executar no sistema. Estes

privilégios podem dar o direito de manipular ou não determinado tipo de objecto. • Um utilizador pode ter ou não o privilégio de criar tabelas. Se não lhe for atribuído

este privilégio, ao tentar criar uma tabela o utilizador está a cometer uma violação de acesso e o Oracle emitirá uma mensagem de erro.

Privilégios de objectos • São atribuído ao utilizador para lhe conceder direitos sobre objectos, tendo sido

esses objectos criados por um utilizador (proprietário deles). Os objectos só podem ser acedidos pelo utilizador que os criou ou pelo administrador da base de dados. Um utilizador pode dar o direito a outro utilizador de executar determinada acção sobre os seus objectos.

• São concedidos habitualmente aos utilizadores finais ou operadores.


Comando GRANT Comando utilizado para a administração de privilégios. Para a concessão de privilégios de sistema: GRANT opção TO utilizador IDENTIFIED BY senha; CONNECT opção que possibilidade de ligação à base de dados; RESOURCE opção que possibilidade de criar tabelas; DBA opção que possibilidades de criar utilizadores; Exemplos: GRANT CONNECT, RESOURCE TO USER1 IDENTIFIED BY SENHA1; Cria um novo utilizador. Também pode ser criado através de CREATE USER. GRANT CONNECT TO USER1 IDENTIFIED BY XPTO1; Altera a senha do utilizador; GRANT DBA TO USER1; Dá o privilégio DBA ao utilizador. Para a concessão de privilégios a outros utilizadores: GRANT privilégios ON objecto TO utilizador; SELECT: privilégio que dá direitos de consultar dados numa tabela ou vista; INSERT: privilégio que dá direitos de inserção de dados numa tabela ou vista; UPDATE: privilégio que dá direitos de actualização de dados numa tabela ou vista; DELETE: privilégio que dá direitos de eliminação de dados numa tabela ou vista; ALTER: privilégio que dá direitos de definição de colunas numa tabela; INDEX: privilégio que dá direitos de definição de índice para uma tabela; REFERENCES: privilégio que dá direitos de referências a uma tabela; ALL: privilégio que dá todos os direitos sobre esse objecto Exemplos: GRANT SELECT ON GRUPO TO USER1; Conceder a USER1 o privilégio de executar SELECT na tabela GRUPO. GRANT UPDATE(COD_FAMILIA,FDESC) ON FAMILIA TO GOMES; Conceder a GOMES o privilégio de alterar colunas específicas à tabela FAMILIA. GRANT INSERT, UPDATE ON GRUPO TO USER1,GOMES; Conceder a USER1 e GOMES os privilégio de inserção e actualização à tabela GRUPO. GRANT ALL ON FAMILIA TO USER1,GOMES; Conceder a USER1 e GOMES todos os privilégios sobre a tabela FAMILIA.


Comando REVOKE Comando utilizado para retirar privilégios aos utilizadores. REVOKE privilégios ON objecto FROM utilizador; Exemplo: REVOKE SELECT ON GRUPO FROM USER1; Retira a USER1 o privilégio de executar SELECT na tabela GRUPO. Passar privilégios concedidos • Quando um utilizador recebe um privilégio não recebe, normalmente, autorização

para passar esse privilégio a outros; • A cláusula WITH GRANT OPTION confere autorização para passar o privilégio

recebido. Exemplo: GRANT SELECT ON GRUPO TO USER1 WITH GRANT OPTION; Privilégio público Permite ao dono de uma tabela conceder acesso a todos os utilizadores com um único comando. Exemplo: GRANT SELECT ON GRUPO TO PUBLIC; Sinónimos Quando um utilizador acede a um objecto que é propriedade de outro utilizador, é necessário o nome do utilizador proprietário e o nome do objecto para referenciar o mesmo. Exemplo; SELECT * FROM USER1.GRUPO; Após a criação de um sinónimo para um objecto de outro utilizador com o comando CREATE SYNONYM, o objecto pode então ser referenciado pelo seu sinónimo. Exemplo; CREATE SYNONIM GRUP FOR USER1.GRUPO; SELECT * FROM GRUP; Os sinónimos podem ser eliminados através do comando DROP SYNONIM.


Grupos de Privilégios (roles) • Podem ser também concedidos aos utilizadores grupos de privilégios designados

por roles, que são criados através do comando CREATE ROLE. • Executando o comando GRANT, a cada role podem ser concedidos vários privilégios

e, por sua vez, pode ser concedido aos utilizadores um ou mais roles. • Também, é possível conceder um role a outro role. • Os privilégios atribuídos aos utilizadores ou aos roles podem ser posteriormente

retirados através da execução do comando REVOKE. Vantagens: • Reduzem e simplificam as tarefas de administração de privilégios; • Permitem a gestão dinâmica de privilégios; • Podem ser protegidos por uma senha (password), pelo que pode haver aplicações

que concedem os roles apenas aos utilizadores da conta que conhecem a senha. Exemplo:

Criação dos Roles CREATE ROLE OARM; Criação de operadores de armazém CREATE ROLE OCONT; Criação de operadores de contabilidade CREATE ROLE AUDITOR; Criação de papel de Auditor

Concessão de privilégios de sistema aos roles GRANT CREATE SESSION TO OARM; GRANT CREATE SYNONYM TO OARM; GRANT CREATE SESSION TO OCONT; GRANT DBA TO AUDITOR;

Concessão de privilégios de objectos aos roles GRANT SELECT, INSERT ON CODPOSTAL TO OARM; GRANT UPDATE ON CODPOSTAL TO OCONT; GRANT ALL ON CODPOSTAL TO AUDITOR;

Concessão dos roles aos utilizadores GRANT OARM TO USER1; GRANT OCONT TO GOMES;

Comando CREATE SCHEMA Comando para criar tabelas, vistas e executar todos os grants necessários através de uma só transacção, definindo toda a estrutura da base de dados. O nome do esquema é sempre o nome do utilizador que possui a base de dados. CREATE SCHEMA AUTHORIZATION AUD CREATE TABLE FORNECEDOR ... GRANT ... CREATE VIEW ... ...


VI. Dicionário de Dados Consiste num conjunto de tabelas e vistas que fornecem um guia de referência só_leitura sobre a base de dados. O dicionário de dados dá-lhe a seguinte informação: • Nome dos utilizadores Oracle;

• Direitos e privilégios concedidos; • Nome dos objectos da base de dados; • Restrições aplicadas a uma tabela; • Informações de auditoria. As tabelas e vistas do dicionário de dados são os primeiros objectos a serem criados automaticamente na base de dados pela instrução SQL CREATE DATABASE e pertencem ao utilizador SYS. Existem três tipos de vistas do SYS (com prefixos USER, ALL, DBA): USER_xxxx - Permitem ao utilizador visualizar informação sobre tabelas criadas pelo utilizador e privilégios concedidos pelo utilizador. ALL_xxxx - Os utilizador podem aceder objectos para os quais lhe foram concedidos direitos de acesso, além dos objectos que possuem. DBA_xxxx - Para utilização pelos utilizadores com privilégios DBA – podem aceder a qualquer objecto da base de dados. Algumas das vistas do dicionário de dados que não utilizam prefixos: DICTIONARY - Lista todas as tabelas, vistas e sinónimos do dicionário de dados acessíveis ao utilizador. DICT_COLUMNS - Lista todas as colunas dos objectos do dicionário acessíveis ao utilizador. CONSTRAINT_DEF - Lista todas as definições de restrição introduzidas nas tabelas acessíveis ao utilizador. CONSTRAINT_COLUMNS - Lista todas as colunas que estão acessíveis para o utilizador actual e referidas em definições e restrições.


A Vista DICTIONARY DICTIONARY lista todos os objectos do dicionário de dados acessíveis ao utilizador com uma breve descrição dos objectos. A seguinte instrução de SQL apresenta o conteúdo da tabela DICTIONARY: SELECT * FROM DICTIONARY; TABLE NAME COMMENTS ACCESSIBLE_COLLUMNS Colunas de todas as tabela, vista e ACCESSIBLE_TABLES Tabela e Vistas acessíveis ao utilizador ALL_CATALOG Todas as tabelas, vistos, sinónimos, e sequências acessíveis ao

utilizador ALL_COL_COMMENTS Comentários em colunas de tabelas e vista acessíveis ALL_COL_GRANTS_MADE Concessões em coluna para as quais o utilizador é proprietário ou

cadente (tem o poder de conceder) ALL_COL_GRANTS_RECD Concessões em colunas para as quais o utilizador ou PUBLIC é o

adquirente (recebe o direito) ALL_CONSTRAINTS Definições de Restrição em tabelas acessíveis ALL_ CONS_COLUMNS Informação sobre colunas acessíveis em definições de restrição ALL_DB_LINKS Ligações à base de dados acessíveis ao utilizador ALL_ DEF_AUDIT_OPTS Opções de auditoria para novos objectos criados ALL_INDEXES Descrições de índices de tabelas acessíveis no utilizador ALL_IND_COLUMNS COLUNAS contendo ÍNDICES em TABELAS acessíveis ALL_OBJECTS Objectos acessíveis ao utilizador ALL_SEQUENCES Descrição de SEQUÊNCIAS acessíveis ao utilizador ALL_SYNONYMS Todos os sinónimos acessíveis ao utilizador ALL_TABLES Descrição de tabelas acessíveis ao utilizador ALL_TAB_COMMENTS Comentários em tabelas e vistas acessíveis ao utilizador ALL_TAB_GRANTS_MADE Concessões de utilizador e concessões dos objectos do utilizador ALL_TAB_GRANTS_RECD Concessões em objectos para os quais o utilizador ou PUBLIC é o

adquirente ALL_USERS Informação sobre todos os utilizadores da base de dados ALL_VIEWS Texto das vistas acessíveis ao utilizador AUDIT_ACTIONS COLUMN_PRIVILEGES Concessões em colunas para as quais o utilizador é o cedente,

adquirente, ou dono, ou PUBLIC é o adquirente CONSTRAINT_COLUMNS informação sobre colunas acessíveis em definições de restrição CONSTRAINT_DEFS Definições de Restrição em tabelas acessíveis DICTIONARY Descrição dar tabelas e vistas do dicionário dedadas DICT_COLUMNS Descrição das colunas nas tabelas e vistas do dicionário de dados DUAL SYSAUDIT_TRAIL Sinónimo de AUDIT_TRAIL


TABLE NAME COMMENTS TABLE_PRIVILEGES Concessões em objectos para os quais o utilizador é o cedente,

adquirente, ou don o, ou PUBLIC é o adquirente USER_ AUDIT_CONNECT Entradas no registo de auditoria relativos às entradas/saídas de

sessão do utilizador USER_AUDIT_TRAIL Entradas no registo de auditoria relevantes para o utilizador USER_CATALOG Tabelas, Vistas, Sinónimos, Sequências acessíveis ao utilizador USER_CLUSTERS Descrições dos "clusters" do utilizador USER_CLU_COLUMNS Correspondência das colunas da tabela para as colunas do

“cluster" USER_COL_COMMENTS Comentários em colunas de tabelas e vistas do utilizador USER_COL_GRANTS Concessões em colunas para as quais o utilizador é o proprietário,

cedente ou adquirente USER_COL_GRANTS_MADE Todas as concessões em colunas de objectos possuídos pelo

utilizador USER_ COL_GRANTS_RECD Concessões em colunas para as quais o utilizador é o adquirente USER_CONSTRAINTS Definições de Restrição em tabelas acessíveis USER_CONS_COLUMNS Informação sobre colunas acessíveis nas definições de restrição USER_CROSS_REFS Referências cruzadas para vistas, sinónimos, e restrições do

utilizador USER_DB_LINKS Ligações à base de dados possuídas pelo utilizador USER_EXTENTS Extensões compreendendo segmentos possuídas pelo utilizador USER_FREE_SPACE Extensões livres em "tablespaces” acessíveis ao utilizador USER_INDEXES Descrição dos índices próprios do utilizador USER_IND_COLUMNS COLUMNS (Colunas) contendo INDEXES (índices) do

utilizador ou em TABLES (Tabelas) do utilizador USER_OBJECTS Objectos possuídos pelo utilizador USER_SEGMENTS Armazenamento atribuído para todos os segmentos da base de

dados USER_SEQUENCES Descrição das SEQ UENCES próprias do utilizador USER_SYNONYMS Os sinónimos privados do utilizador USER_TABLES Descrição das tabelas próprias do utilizador USER_TABLESPACES Descrição dos "tablespaces" acessíveis USER_TAB_AUDIT_OPTS Opções de auditoria para as tabelas e vistas próprias do utilizador USER_TAB_COLUMNS Colunas de tabelas, vistas e "clusters" do utilizador USER_TAB_COMMENTS Comentários nas tabelas e vistas possuídas pelo utilizador USER_T AB_G RANTS_RECD Concessões em objectos para os quais o utilizador é o adquirente USER_TAB_GRANTS_MADE Todas as concessões em objectos possuídos pelo utilizador USER_TAB_GRANTS Concessões em objectos para os quais o utilizador é o adquirente USER_ TS_ QUOTAS Quotas de "Tablespace” para o utilizador USER_USERS Informação sobre o utilizador actual USER_VIEWS Texto das vistas possuídas pelo utilizador


Algumas Vistas (Views) Úteis Nome Vista Sinónimo Descrição DICTIONARY Dict Lista de todos os objectos da BASE de dados USER_OBJECTS Obj Objectos possuídos pelo utilizador USER_CATALOG Cat Tabelas, vistas, sinónimos e sequências acessíveis ao utilizador USER_TABLES Tabs Descrição das tabelas do utilizador USER_TAB_COLUMNS Cols Colunas das tabelas e vistas do utilizador USER_COL_COMMENTS Comentários em colunas das tabelas e vistas do utilizador USER_TAB_COMMENTS Comentários em tabelas e vistas possuídas pelo utilizador USER_SEQUENCES Descrição das sequências próprias Seq do utilizador USER_SYNONYM Syn Sinónimo privado do utilizador USER_VIEWS Texto de vistas possuídas pelo utilizador USER_INDEXES Ind Descrição dos índices próprios do utilizador ALL_OBJECTS Objectos acessíveis ao utilizador ALL_TAB_COL Colunas para todos as tabelas e vistas acessíveis ao utilizador SQL> DESC USER_OBJECTS Nome Tipo ----------------------------------------------------------- OBJECT_NAME VARCHAR2(128) SUBOBJECT_NAME VARCHAR2(30) OBJECT_ID NUMBER DATA_OBJECT_ID NUMBER OBJECT_TYPE VARCHAR2(18) CREATED DATE LAST_DDL_TIME DATE TIMESTAMP VARCHAR2(19) STATUS VARCHAR2(7) TEMPORARY VARCHAR2(1) GENERATED VARCHAR2(1) SECONDARY VARCHAR2(1) SQL> select object_name from user_objects; OBJECT_NAME ------------------------------------------- BONUS DEPT EMP PK_DEPT PK_EMP SALGRADE VISTA1 10 linhas seleccionadas.


VII. Transacções

Mecanismo que valida (ou anula) conjuntos de operações básicas na base de dados de uma maneira atómica:

Ou todas as operações elementares pertencentes à transacção são confirmadas, ou são anuladas e é como se nunca tivessem existido.

INSERT DELETE UPDATE DELETE INSERT INSERT

Tempo

INSERT

TRANSACÇÃO TRANSACÇÃO

COMMIT COMMITou

ROLLBACK

Existem dois requisitos das transacções: • Correcção: garantia da consistência da informação;

(é da responsabilidade do programador) • Atomicidade: todas as operações associadas à transacção são executadas ou

nenhuma é. (é da responsabilidade do SGBD)

Instruções DML, DDL e transacções (Oracle) • Transacções DML – Podem conter qualquer número de instruções DML. • Transacções DDL – Apenas podem conter uma instrução DML.

INSERT DELETE CREATETABLE

DELETE INSERT INSERTINSERT

TRANS. DML

Termina transacção correntee inicia uma nova transacção

....

TRANS. DLL TRANS. DML

....

Termina transacção DDL einicia uma nova transacção


Processamento de transacções • Uma transacção começa quando é encontrado o primeiro DML (a seguir ao fim da transacção anterior). • Uma transacção termina com: COMMIT a transacção é confirmada; ROLLBACK a transacção é abortada; Comando DDL a transacção é confirmada; Detecção de erros a transacção é abortada; Saída (EXIT) da sessão SQL a transacção é confirmada; Savepoints • Permitem guardar todas as alterações efectuadas desde o inicio da transacção corrente, ou desde o último Savepoint; • Não terminam a transacção, apenas guardam as alterações efectuadas; • Úteis em transacções muito longas; • Pode-se fazer ROLLBACK para um Savepoint, anulando apenas as alterações introduzidas depois desse Savepoint; • Depois do ROLLBACK to Savepoint a transacção continua activa; • Quando a transacção termina todos os Savepoints são eliminados.

COMMIT Savepoint S1 Savepoint S2 ROLLBACK to S2 COMMIT


Durante uma Transacção Enquanto as alterações introduzidas durante a transacção não forem confirmadas (COMMIT), estas alterações: - são visíveis para o dono da conta; - são invisíveis para os outros utilizadores (estes vêem o estado após o último

COMMIT); - podem ser anuladas através de ROLLBACK; - podem ser anuladas parcelarmente através de ROLLBACK para um Savepoint. Transacções e transparência para o programa O controlo (início/fim) das transacções é explícito e visível para o programador/utilizador. O programador é responsável por definir as operações que devem ser executadas atomicamente através do mecanismo das transacções. Atomicidade e consistência dos dados (exemplo): Lançamento de 100 contos numa contabilidade duma empresa. 1. Debitar os 100 conto na conta caixa 2. Creditar os 100 contos na conta Clientes.

COMMIT Débito Crédito COMMIT ......TRANSACÇÃO

Execução de comandos DML em SQL e controlo das transacções


• A execução bem sucedida de um comando DML Todo o comando foi executado sem erros de uma maneira atómica (ex. todos os registos seleccionados foram actualizados). • As alterações efectuadas por um comando só ficam permanentes quando ocorrer o COMMIT da transacção. ROLLBACK ao nível do comando SQL • Se, durante a fase de execução de um comando DML, for detectado um erro é feito ROLLBACK do comando (é como o comando nunca tivesse sido iniciado). • Possíveis erros detectados: - tentativas de violação de integridade; - incompatibilidade de dados. • Todas as alterações provocadas pela execução principal do comando (até à detecção do erro) são desfeitas. Utilização de Savepoints (exemplo) . . INSERT INTO GRUPO VALUES (1,’Material de Escritório, null); SAVEPOINT INSERT_CONCLUIDO; UPDATE ARTIGO SET COD_GRUPO = 1,COD_FAMILIA = 2; ROLLBACK TO INSERT_CONCLUIDO; (Anula comando de update) UPDATE ARTIGO SET COD_GRUPO = 1,COD_FAMILIA = 2 WHERE ANOME=‘caneta bic preta’; (Comando de update revisto) COMMIT;


Instruções SQL para controlo de transacções (COMMIT, SAVEPOINT, ROLLBACK) COMMIT [WORK] Termina explicitamente a transacção corrente. - Torna definitivas as alterações efectuadas durante a transacção; - Elimina todos os Savepoints efectuados durante a transacção; - Liberta os bloqueios da transacção. (Recordar que: A transacção também pode terminar de uma maneira implicita) SAVEPOINT <Nome do Savepoint> Guarda as alterações efectuadas até esse ponto da execução da transacção: - Usado para dividir uma transacção em partes mais pequenas; - Em caso de engano é possível desfazer as alterações feitas e retomar o estado a

partir de um Savepoint estabelecido anteriormente; - Se for criado um segundo Savepoint com o mesmo nome de um anterior o

savepoint anterior é apagado. - Limite para o número de Savepoints por transacção em Oracle é 5. ROLLBACK [WORK] TO [SAVEPOINT] <Nome do Savepoint> • ROLLBACK TO <Nome do Savepoint> - Desfaz as alterações efectuadas desde o Savepoint mencionado; - Liberta bloqueios estabelecidos depois do Savepoint. • ROLLBACK - Termina a transacção abortando-a; - Desfaz todas as alterações efectuadas desde o início da transacção; - Apaga todos os Savepoints; - Liberta os bloqueios da transacção.


Consistência da Informação • Dois tipos de acesso à base de dados: - Operações de leitura (select); - Operações de escrita (Insert, Update, Delete). • Problemas: garantir que - As operações de leitura não visualizam dados em processo de alteração; - As operações de escrita são feitas de modo consistente, e as alterações feitas por

um utilizador não entram em conflito com as alterações que outro utilizador esteja a fazer.

Segmentos do Rollback • Partes da base de dados onde são registadas as acções de uma transacção que podem vir a ser desfeitas (rolled back) em certas circunstâncias; • Os segmentos de rollback contêm os valores antigos relativos a todas as alterações efectuadas a dados durante uma transacção; • Cada base de dados contêm um ou mais segmentos de rollback; • Os segmentos de rollback são uma estrutura interna manipulada pelo SGBD e não pode ser acedida pelos utilizadores nem pelo administrador da base de dados. • Os segmentos de rollback são usados para: - Assegurar a consistência de leituras;

• Garantir que cada utilizador vê os dados conforme eles existem no momento da ultima confirmação (commit);

• Só depois de confirmados (pelo commit da transacção corrente) é que as últimas alterações se tornam visíveis para todos os utilizadores.

- Efectuar o rollback de transacções; - Recuperação após falha.


Uso de segmentos de Rollback

Utilizador ATransacção T1

Novo valor doregisto

UPDATE ARTIGO SET COD_GRUPO = 1WHERE ANOME=‘caneta bic preta’;

Identificação daalteração e valorantigo do registo

Blocos dedados

Segmentosde rollback

Leituras durante a transacção

Utilizador ATransacção T1

UPDATE ARTIGO SET COD_GRUPO = 1WHERE ANOME=‘caneta bic preta’; As leituras durante

T1 são feitas sobre osdados alterados

Blocos dedados


SELECT * FROM GRUPOWHERE ANOME>‘b’;

Utilizador BTransacção T2

Dados nãoalterados

Blocos dedados


SELECT * FROM GRUPOWHERE ANOME>‘b’;

Imagem daconsistência

de leitura

Dadosantigos

Outros utilizadores vêem os dados como noinício da transacção T1 do utilizador A


Transacções só de leitura • O SGBD garante, por defeito, que os resultados obtidos por uma instrução SELECT (consulta) são sempre consistentes; • Para garantir que os resultados obtidos por um dado conjunto de consultas são consistentes é necessário incluir instruções específicas; • Numa transacção só de leitura todas as instruções vêem os dados no estado (consistente) relativo ao início da transacção. Alterações efectuadas a esses dados por outros utilizadores não são visíveis durante a transacção só de leitura; • Estas transacções usam segmentos de rollback de modo semelhante ao usado na consistência de leitura ao nível da instrução. Consistência nas transacções só de leitura

COMMIT

COMMIT

Utilizador X

Fim da transacçãosó de leitura

Início datransacção só de

Utilizador ACOMMIT

COMMITUtilizador B

COMMITUtilizador C

COMMIT

Tempo

Usar transacções só de leitura • Começam pelo comando SET TRANSACTION READ ONLY; • Só admitem consultas (SELECT); • A transacção só de leitura termina quando for executado um Commit, Rollback ou uma instrução DDL.


Exemplo : ... COMMIT; SET TRANSACTION READ ONLY; SELECT ANOME , ADESC FROM ARTIGO; SELECT ANOME ,SMIN*2 FROM ARTIGO; SELECT ANOME || ADESC FROM ARTIGO; COMMIT; Outros aspectos sobre segmentos de Rollback • Sempre que começa uma transacção é atribuído um segmento de rollback a essa transacção; • Cada segmento de rollback pode tratar mais do que uma transacção; • Durante a transacção, por cada alteração efectuada é guardado (entre outras coisas) o valor antigo do segmento de rollback correspondente; • Durante a transacção, o registo correspondente a cada alteração é ligado ao registo correspondente à alteração anterior, de modo a facilitar as leituras e/ou o rollback; • No caso de existir savepoints, as alterações são relacionadas com o savepoint correspondente; • Em caso de necessidade são atribuídos novos segmentos de rollback à transacção. Segmentos de Rollback: commit • Quando uma transacção termina por commit a informação de rollback é libertada; • Contudo, permanecerá no segmento de rollback de modo a fornecer uma visão consistente dos dados, no caso de existir consultas (de outros utilizadores) sobre esses dados que tenham começado antes do commit; • Só quando a informação de rollback já não é necessária para garantir a consistência de leituras permanentes é que é destruída.


Segmentos de Rollback: rollback • Todas as alterações efectuadas durante a transacção são desfeitas usando a informação de rollback armazenada no(s) segmento(s) correspondente(s); • No caso de ROLLBACK TO SAVEPOINT só são desfeitas as alterações efectuadas depois do savepoint. A utilização dos segmentos de rollback é semelhante ao caso anterior.


VIII. Concorrência e consistência Objectivos no controle da concorrência: • Garantir a consistência dos dados; • Maximizar a concorrência, e permitir que os dados sejam utilizados/manipulados

por um grande número de utilizadores. Problemas inerentes à concorrência • Leituras inconsistentes:

Quando os dados devolvidos por uma instrução de consulta reflectem alterações introduzidos e/ou confirmadas na base de dados durante a execução da instrução de consulta;

• Leituras não reprodutíveis:

Quando, numa mesma transacção, duas consultas aos mesmos dados mostram informação diferente, devido a alterações entretanto confirmadas por outras transacções;

• Leituras erróneas:

Quando, numa transacção, são lidos dados ainda não confirmados por outra transacção;

• Perda de actualizações:

Quando a actualizarão de um registo numa transacção é efectuada sobre valores alterados mas ainda não confirmados por outra transacção.

Bloqueios (locking) • Mecanismo utilizado para controlar o acesso concorrente aos mesmos dados; • Impede a actualizarão simultânea dos mesmos dados por dois ou mais

utilizadores; • Impede alterações na definição de uma tabela ou de uma coluna enquanto

estiveram a decorrer transacções que actualizem os dados da tabela ou coluna.


Quando é necessário efectuar bloqueios? • Sempre que um utilizador tenta introduzir alterações na base de dados (acessos

de escrita); • Nunca são necessários bloqueios quando o acesso à base de dados é de leitura;

- Os acessos de leitura nunca bloqueiam os acessos de escrita; - Os acessos de escrita nunca bloqueiam os acessos de leitura; - Só acessos de escrita podem bloquear outros acessos de escrita.

Bloqueios: ideia básica • Durante uma transacção, todos os registos (tabelas) alterados são

automaticamente bloqueados de modo a impedir que outras transacções os possam alterar simultaneamente;

• Se uma transacção tentar alterar um objecto previamente bloqueado por outra

transacção ficará suspensa em lista de espera até que esse objecto seja libertado; • No final de uma transacção todos os objectos bloqueados pelas instruções dessa

transacção são libertados. Funcionamento dos bloqueios (exemplo)

UPDATE ALUNOSSET MEDIA= MEDIA* 1.05WHERE CURSO= 10;

COMMIT;

COMMIT;

UPDATE ALUNOS ALUNOSSET NOME ='Jorge'WHERE NUM= 1504;

ALUNOSNome Num Curso MediaMaria 1504 10 12Luisa 953 10 16João 1023 40 11Daniel 878 30 15Cristina 1000 10 17


Tipos de bloqueios • Bloqueio do dicionário de dados:

- permite controlar o acesso à definição de objectos na base de dados (e.g. tabelas através de instruções CREATE TABLE, ALTER TABLE, DROP TABLE);

- é controlado automaticamente pelo SGBD.

• Bloqueio de manipulação de dados:

- permite controlar o acesso aos dados nas tabelas; - o SGBD bloqueia implicitamente as tabelas/registos que estão a ser

alterados por um utilizador;

- um utilizador pode adquirir explicitamente um bloqueio numa tabela da base de dados.

Níveis de bloqueio (dados) • Bloqueio de tabela - aplica-se a toda a tabela; • Bloqueio de registo - aplica-se apenas a um registo de uma dada tabela.


Tipos de bloqueio implícito (Oracle) Exclusivo (X);

- Permite consultas ao recurso bloqueado (registo ou tabela) mas não permite qualquer outro acção sobre o recurso;

Exclusivo de registos (RX):

- Permite o acesso concorrente a uma tabela impedindo outros utilizadores de bloquearem toda a tabela para acesso exclusivo;

- Vários utilizadores podem bloquear registos individuais na tabela e

efectuar e confirmar alterações simultaneamente; - Registos bloqueados podem ser consultados mas só poderão ser alterados

quando os bloqueios forem libertados. Aquisição implícita de bloqueio (Oracle)

Nível de bloqueio Acção do Utilizador Registo Tabela SELECT Sem bloqueio INSERT X RX UPDATE X RX DELETE X RX DDL - X


Exemplo de bloqueios implícitos Ambos utilizadores adquirem bloqueio exclusivo de registos (RX) sobre a tabela

Utilizador B UPDATE ALUNOS SET MEDIA= MEDIA* 1.05 WHERE CURSO= 10; Bloqueio Exclusivo do Registo (RX)

Utilizador A COMMIT; UPDATE ALUNOS ALUNOS SET NOME ='Jorge' WHERE NUM= 1504; Bloqueio Exclusivo do Registo (RX)

ALUNOS Nome Num Curso Media Maria 1504 10 12 Luisa 953 10 16 João 1023 40 11 Daniel 878 30 15 Cristina 1000 10 17

Bloqueio explícito

Um utilizador pode adquirir explicitamente um bloqueio quando:

- Pretende consultar dados em várias tabelas e quer ter a certeza de obter uma visão consistente dos dados nas tabelas;

- Uma transacção necessita alterar dados com base em outros dados que não

podem ser alterados até a transacção estar concluída. Aquisição de bloqueios explícitos Através das instruções SQL: SELECT ... FOR UPDATE OF LOCK TABLE


SELECT... FOR UPDATE OF [NOWAIT] • Utiliza-se quando:

- está previsto actualizar um dado conjunto de registos. O comando efectua uma consulta para identificar todos os registos a actualizar e, de seguida, bloqueia os registos seleccionados;

- é necessário bloquear um registo (ou registos) porque se vai fazer uma actualizarão para qual é necessário garantir que esse registo não é entretanto alterado por outro utilizador.

• Os bloqueios adquiridos por SELECT... FOR UPDATE são libertados quando for

efectuado um COMMIT ou um ROLBACK. • A opção NOWAIT faz com que o SELECT termine, em vez de esperar, no caso de

um dos registos seleccionados já ter sido bloqueado por outro utilizador. LOCK Table

- Aquisição explícita de um bloqueio - LOCK TABLE <nome da tabela> IN <tipo de bloqueio>

- Os tipos de bloqueio são:

- Exclusive - Row Exclusive

Impasses (dead locks)

- Podem gerar-se situações de impasse quando dois ou mais utilizadores tentam aceder aos mesmos dados e cada utilizador fica à espera dos objectos detidos pelo outro utilizador.


Impasses (exemplo):

Transacção B UPDATE ALUNOS ALUNOS SET NOME = 'Joana' WHERE NUM=953; UPDATE ALUNOS SET NOME =’Manuel’ WHERE NUM= 1504;

Transacção A UPDATE ALUNOS ALUNOS SET NOME ='Jorge' WHERE NUM= 1504; UPDATE ALUNOS SET MEDIA= MEDIA* 1.05 WHERE NUM= 953;

Não pode continuar porque o registo do aluno Num=953 está bloqueado na Transacção B

Não pode continuar porque o registo do aluno Num=1504 está bloqueado na Transacção A

Como lidar com impasses • Prevenir os impasses Usa-se em sistemas em que a probabilidade de surgirem impasses é muito elevada.

1) Bloquear explicitamente, no inicio da transacção, todos os recursos que se

pretende vir a alterar: - Afecta a utilização partilhada dos recursos; - Pode deixar transacções à espera durante períodos muito longos.

2) Impor uma ordem para o bloqueio dos recursos e garantir que todas as transacções

seguem essa ordem - Pode ser de difícil concretizarão para certas aplicações.

• Detectar os impasses e recuperar dessa situação Usa-se em sistemas em que a probabilidade de surgirem impasses é baixa. 1) Grafo à-espera-de (wait-for graph)

- O SGBD mantém um grafo dirigido que representa as transacções que estão

à espera que recursos bloqueados por outras transacções sejam libertados. 2) Este grafo é analisado periodicamente pelo sistema para detectar situações de

impasse.


Grafo à-espera-de (wait-for graph)

- Cada nó representa uma transacção; - Cada arco indica que a transacção representada pelo nó de partida está à

espera da transacção representada pelo nó de chegada.

T1

T3

T2T4

- A transacção TI está à espera da transacção T2- A transacção TI está à espera da transacção T3- A transacção T2 está à espera da transacção T4

Manutenção do grafo à-espera-de SGBD vai mantendo actualizado o estado do grafo:

- Sempre que uma transacção é iniciada o sistema acrescenta um novo nó ao grafo;

- Sempre que urna transacção fica à espera que um recurso seja libertado por

outra transacção o sistema acrescenta um arco; entre os nós em causa;

- Sempre que um recurso é libertado o grafo é actualizado, se necessário:

- Se o recurso foi libertado porque a transacção que o bloqueava terminou, então o nó correspondente a essa transacção é eliminado e com ele todos os arcos que chegavam a esse nó;

- Se o recurso foi libertado porque a transacção que o bloqueava fez rollback to

savepoint, então, se isso implicar o fim da espera de uma transacção, o arco correspondente é retirado do grafo.


Detectar impasses através do grafo à-espera-de Existe um impasse sempre que o grafo à-espera-de contém um ciclo.

T1

T3

T2

T4

Está à espera de

Quando deve o sistema examinar o grafo? • Sempre que o bloqueio de um recurso não pode ser satisfeito de imediato, se a

probabilidade de se gerarem impasses é elevada; • Periodicamente, se a probabilidade de se gerarem impasses é reduzida. O período

deve estar relacionado com a probabilidade de surgirem impasses e o número de transacções potencialmente afectadas.

O que acontece quando é detectado um impasse? • É necessário fazer rollback a uma (ou mais) transacções de modo a quebrar o

impasse; • Critérios na escolha da vítima (minimizar os custos):

- Escolher a transacção que tenha alterado menos dados até então; - Escolher a transacção que tenha mais dados ainda a manipular até terminar; - Escolher a transacção que tenha savepoints de tal modo que o rollback para

um savepoint possa quebrar o impasse e minimize a perda de dados.


IX. Bases de dados distribuídas Arquitectura cliente-servidor Este tipo de arquitectura, envolve normalmente uma rede local de computadores que acedem à mesma base de dados, ao contrário da arquitectura clássica de teleprocessamento de base de dados, em que existem vários terminais estúpidos a acederem a uma só máquina. A arquitectura cliente-servidor envolve vários computadores a processarem informação conjuntamente como se pode verificar na seguinte figura.

Cliente Cliente Cliente

Base deDados

Servidor

Rede

O servidor contém a “máquina da base de dados” propriamente dita, tratando também das tarefas relacionadas com a partilha de dados, controlo de concorrência, segurança e tolerância de falhas. O cliente estabelece o interface com o utilizador executando uma aplicação de utilizador. O cliente e servidor podem ser executados no mesmo computador, mas a solução distribuída é muito mais vantajosa.


Funções de cada computador cliente:

• Gere o interface com o utilizador, • Aceita os dados que o utilizador introduz, • Processa a lógica das aplicações, • Gera requisições à base de dados, transmite as requisições ao servidor, recebe

os resultados do servidor e formata os resultados. Funções do servidor:

• Aceita as requisições do computador cliente, processa-as e dá-lhe resposta; • Controla a integridade dos dados; • Processa os acessos concorrentes aos dados; • Reposição de dados; • Optimização de querys; • Actualizações à base de dados.

O processamento distribuído na arquitectura cliente-servidor concede-nos as seguintes vantagens:

• Independência das aplicações de cliente relativamente à localização física dos dados;

• Todo o trabalho de interface com o utilizador e tratamento da informação (gráfico, formatação, etc.) é feito e optimizado no cliente;

• Todas as tarefas de armazenamento da informação, consulta, segurança, partilha de dados, etc. são concentradas e optimizadas no servidor;

• Só os pedidos de informação e os resultados é que são enviados pela rede, donde resulta um trafego na rede geralmente muito baixo;

• Adapta-se facilmente a problemas de diferentes dimensões (mais ou menos clientes, servidores com maior capacidade, mais do que um servidor).


Arquitectura Multitier

• Arquitectura web em conjunto com arquitectura cliente servidor.

• As entidades continuam ser as mesmas: o cliente ao servidor. O que difere é a

existência de um servidor Web e a forma como os utilizadores efectuam os seus pedidos.

• Servidor e cliente estão passíveis de comunicar porque usam as mesmas regras

ou protocolos, definidos pela arquitectura cliente/servidor.

• Para aceder a um página www, o utilizador usa um web browser www (ex. Internet Explorer, Netscape, Navigator) que funciona como cliente em relação ao servidor web, a comunicação é feita por TCP/IP, onde é usado o protocolo HTTP (Hipertext Transfer Protocol).

• Vantagens

Maior escalabilidade – capacidade de responder ao aumento de procura de serviços sem degradar a performance.


Base de Dados Distribuída Uma base de dados distribuída surge ao utilizador como se fosse uma única base de dados, mas na realidade é constituída por diversas bases de dados distribuídas por diversos computadores.

Base deDados

AServidor

Rede

Servidor

Base deDados

B

Cliente Cliente

Cliente

Nós deSistema


Clientes e Servidores

Base deDados

AServidor

Rede

Servidor

Base deDados

B

TabelaArtigo

TabelaFornecedor

INSERT INTO ARTIGO@B;

DELETE FROM FORNECEDOR;

SELECT ... FROM ARTIGO@B;

COMMIT;

Durante a execução destes comandos o computador dabase de dados A funciona como cliente

Durante a execução deste comando o computador dabase de dados A funciona como servidor


Autonomia local Cada servidor que participa na base de dados distribuída é administrado (contas, segurança, backups, etc.) separadamente e independentemente dos outros servidores. Vantagens:

- Os nós do sistema podem espelhar mais facilmente a estrutura lógica das organização onde se inserem;

- Os dados locais são controlados por um administrador local, pelo que o

domínio de administração é menor e mais manejável;

- Independência de falhas -> Maior disponibilidade;

- A recuperação de falhas pode, em muitos casos; ser efectuada numa base estritamente local;

- Os nós servidores podem ter a dimensão mais adequada a cada problema

local e crescer independentemente. Resolução de nomes • Cada objecto (e.g., tabela) de qualquer esquema existente na base de dados

distribuída tem de ter um nome unívoco; • Resolução de nomes consiste no processo de resolver as referências a objectos

na base de dados distribuída identificando-os univocamente.


Abordagem hierárquica da resolução de nomes • Nomes de objectos locais

- SGBD garante a univocidade de nomes dentro de cada esquema;

- O SGBD garante a univocidade de nomes de esquemas em cada base de dados

local;

- Cada dicionário local só contém nomes dos objectos locais.

• Nomes globais

- Cada base de dados local que participa na base de dados distribuída tem um nome global unívoco (nome da base de dados + domínio da rede que contém a base de dados). No Oracle este mecanismo não é automático;

SELECT * FROM [email protected];

esquema objecto base de dados domínio

Comandos remotos e distribuídos - Interrogação remota

Selecciona (Select) informação de uma ou mais tabelas todas residentes no mesmo nó remoto.

- Actualização remota

Modifica dados numa ou mais tabelas todas residentes no mesmo nó remoto.

- Interrogação distribuída Selecciona informação de dois ou mais nós.

- Actualização distribuída

Modifica dados em dois ou mais nós. Transacções remotas e distribuídas


- Transacção remota

Contém um ou mais comandos remotos, todos referenciando o mesmo nó.

- Transacção distribuída Inclui comandos que acedem a dados em dois ou mais nós distintos.

Transacções distribuídas

• Uma transacção distribuída termina com commit em todos os servidores que participam na transacção, ou então termina com rollback em todos os servidores;

• O mecanismo/protocolo mais conhecido para garantir a execução de transacções

distribuídas é o two-phase commit.

Transparência numa base de dados distribuída

- Na localização física de objectos; - Nas interrogações e actualizações distribuídas; - Nas transacções distribuídas; - Na replicação de objectos.

Transparência na localização de objectos • Quando um utilizador pode referenciar uma mesma tabela sempre da mesma

maneira, independentemente do nó a que se liga; • Pode ser obtida através de vistas e sinónimos.

Vantagens: - Simplifica acesso remoto; - A localização física dos objectos pode ser alterada sem que isso tenha impacto

nos utilizadores finais ou nas aplicações.


Vistas e transparência na localização de objectos

• As vistas locais fornecem transparência na localização para tabelas locais e remotas:

CREATE VIEW AL_CURSOS AS SELECT ACURSO, ANOME, DNOME FROM ACAD.ALUNO A, [email protected] B WHERE A.NCURSO = B.NCURSO;

• Quando os utilizadores acedem à vista AL_CURSOS não precisam saber onde é

que os dados estão localizados: SELECT * FROM AL_CURSOS;

Transparência na localização através de vistas

Base deDados

AServidor

Rede

Servidor

Base deDados

B

TabelaPrinc.Curso

TabelaAcad.Aluno

Cliente

VistaAl_Cursos

Sinónimos e transparência na localização de objectos • Os sinónimos também podem conferir transparência na localização dos

objectos, pois escondem a identidade dos objectos referidos; • Se o objecto referido pelo sinónimo for mudado para outro sítio só é necessário

alterar a definição do sinónimo; • Os sinónimos devem ser públicos e têm de ser declarados em todos as bases de

dados locais. CREATE PUBLIC SYNONIM CUR FOR [email protected];


Transparência nas interrogações e actualizações distribuídas • Os comandos DML (Select, Insert, Update, Delete,... ) devem poder ser usados

para acessos remotos e distribuídos como se fosse para acessos locais Exemplos:

INSERT INTO [email protected] SELECT * FROM CUR; SELECT ACURSO, ANOME, DNOME FROM ACAD.ALUNO A, [email protected] B WHERE A.NCURSO = B.NCURSO; Transparência nas transacções distribuídas • Quando as transacções distribuídas são controladas pelos mesmos comandos

standard (Commit, Savepoint, Rollback) das transacções locais, sem necessidade de qualquer outra acção:

- Comandos numa transacção podem referenciar qualquer número de tabelas

locais ou remotas;

- O SGBD garante que todos os nós envolvidos na transacção tomam a mesma acção; ou fazem todos commit ou todos rollback;

- Se há uma falha na rede durante a transacção distribuída o sistema deve

garantir que a transacção é resolvida globalmente sem necessidade de intervenção explícita.


Transparência na replicação de objectos

• SGBD deve ter mecanismos para, de uma maneira transparente replicar certos objectos muito críticos;

• Por exemplo, manter cópias de uma mesma tabela em vários pontos da base de

dados distribuída pode ter interesse se:

- A tabela é interrogada muito frequentemente, pelo que uma cópia local melhora a velocidade;

- A tabela é modificada muito raramente, pelo que o custo da gestão de réplicas é baixo;

- Se uma das cópias falhar o sistema deverá permitir o acesso a uma réplica da tabela localizada noutro nó.

Notar que as transacções garantem (se bem usadas) a consistência de dados replicados.

Gestão de tabelas replicadas numa base de dados distribuída • Actualização síncrona

- Utilizando triggers para desencadear a actualização (atómica) de todas as réplicas assim que uma delas é alterada.

• Actualização assíncrona (tabela mestre)

- Há uma tabela mestre e um número arbitrário de réplicas;

- Só a tabela mestre é actualizada; as réplicas são só de leitura;

- As réplicas são periodicamente actualizadas de modo a reflectir as últimas alterações na tabela mestre.


Atomicidade nas transacções distribuídas Problema:

- Garantir que numa transacção distribuída os nós envolvidos na transacção ou fazem todos commit ou fazem todos rollback.

Surge quando:

- Uma transacção contém comandos DML que referenciam objectos remotos (usando o nome global do objecto) com o objectivo de modificar os dados neles contidos.

- (Se um nó remoto é referenciado apenas para leitura, não necessita de

participar nas acções que garantem execução atómica da transacção.) Two-phase commit • Fase de preparação

- O coordenador global (nó que inicia o processo começando a executar o comando Commit) pergunta aos nós que participam na transacção se estão preparados para terminar a transacção (commit ou rollback).

• Fase de conclusão (commitphase)

- Se todos os participantes respondem ao coordenador que estão preparados, então o coordenador manda todos efectuar o commit;

- Se algum dos participantes diz que não está preparado então o coordenador

manda todos os nós envolvidos efectuar rollback.


Fase de preparação Em resposta ao nó coordenador (para preparar o fim da transacção) cada nó participante pode responder uma de três coisas: - Preparado

Todos os dados do nó referidos pelos comandos DMI, da transacção distribuída já foram modificados e o nó está preparado para terminar a transacção;

- Só-de-leitura Os comandos executados na transacção não alteraram dados no nó, pelo que não é necessária qualquer preparação;

- Abortar Ocorreu um erro e o nó não está preparado para terminar a transacção com êxito.

Passos na fase de preparação Depois de ter recebido ordem para se preparar um nó executa os seguintes passos: - Indica aos seus descendentes, se houver, (nós subsequentemente referidos por este

nó) para se prepararem; - Reserva todos os recursos necessários para fazer o commit; - Efectua uma série de acções de modo a garantir que os dados bloqueados (os que

foram alterados) vão sobreviver a eventuais falhas; - Responde ao nó que lhe ordenou para se preparar, de acordo com o resultado da

sua fase de preparação. Insucesso na fase de preparação Quando um nó não se consegue preparar para terminar a transacção com êxito:

- Efectua rollback da parte local da transacção;

- Liberta todos os recursos afectos a essa transacção;

- Responde ao nó que lhe solicitou para se preparar a indicar que abortou a transacção.

Estas acções são propagadas aos outros nós envolvidos.


X. Aspectos físicos de uma base de dados

• Como são armazenadas as tabelas e outros objectos? • Que possibilidade tem o programador (e o administrador) de optimizar/afinar:

- espaço em disco - velocidade

Tablespace e ficheiros (Oracle) Uma base de dados é composta por uma ou mais unidades lógicas designadas por tablespaces.

Índice

TablespaceTabela

Tabela

TablespaceTablespace

Índice

Base de Dados

FicheiroFicheiro

Objectos

Tabela

• Cada tablespace é composto por um ou mais ficheiros, mas cada ficheiro só pode ser associado a um tablespace.

• Os objectos da base de dados podem espalhar-se por vários ficheiros, ou seja, a

mesma tabela pode estar contida em dois ficheiros diferentes. • A cada utilizador é atribuído um tablespace por defeito e a cada tablespace pode

ser atribuído um valor fixo ou um valor ilimitado.


• Eventualmente, poderão ser atribuídos ao utilizador direitos de utilização noutros tablespaces.

• Existe também um tablespace do sistema que é criado automaticamente cada vez que uma base de dados é instalada.

Este contém: - O dicionário de dados para a base de dados; - Todos os objectos PL/SQL (procedimentos, funções e triggers);

- Pode também conter dados de utilizadores, embora o mais adequado seja ter

outros tablespaces para esse fim. • O Administrador pode ainda:

- Criar novos tablespaces; - Eliminar tablespaces existentes;

- Acrescentar ou retirar ficheiros a um tablespace;

- Alterar parâmetros (relacionados com o armazenamento dos dados) em

tablespaces existentes.


Unidades lógicas de atribuição/libertação de espaço Cada tablespace é composto por uma hierarquia de unidades lógicas. A hierarquia das unidades lógicas de atribuição e libertação de espaço utilizadas pelo Oracle pode ser descrita da forma seguinte: • Um tablespace é composto por vários segmentos; • Um segmento é composto por vários extents; • Um extent é composto por vários blocos de dados.

2K 2K

2K 2K 2K

2K

Extent28K

2K

2K

Extent84K

Segmento112K

2K

2K2K

2K2K

2K2K

2K2K

2K

2K

2K

2K

2K

2K

2K

2K

2K

2K

2K

2K

2K

2K

2K

2K

Tabespaces são compostos por segmentos

blocos de dados


Unidades Lógicas • segmento é a unidade lógica utilizada para armazenar objectos da base de dados e

cada um dos objectos pertence a só um segmento. • A atribuição de um segmento a uma tabela é feita automaticamente pelo Oracle no

acto da criação da tabela. • Quanto aos segmentos, são constituídos por extents, que só lhes são atribuídos à

medida que vão sendo necessários e que não permanecem contíguos no espaço físico.

• Um extent é constituído por um determinado número de blocos de dados, que

permanecem sempre contíguos e armazenam um determinado tipo de informação. • O bloco de dados é o nível mais fino a que é atribuído espaço, e tem um valor

constante para cada base de dados. (2K é o valor utilizado na maioria das base de dados).

Formato de um bloco de dados

Cabeçalho

Cabeçalho comum (header)Contém informação genérica sobre o bloco.(endereço do bloco, tipo de segmento, etc.)

Directoria de tabelas (table directory)Contém informação acerca das tabelas quetêm informação no bloco.

Directoria de registos (row directory)Contém informação sobre os registosarmazenados no bloco.

ESPAÇO LIVRE

ESPAÇO OCUPADO


Atribuição de espaço ás unidades lógicas • Quando um segmento é criado, é-lhe atribuído um extent inicial. No acto da

criação de uma tabela, o espaço ocupado pelo extent inicial é logo reservado. O valor do extent inicial é por defeito 5K e tem o valor mínimo de 2K.

• Quando os blocos de dados do extent inicial estiverem cheios o Oracle atribui ao

segmento um novo extent. Este novo extent vai piorar a performance da base de dados, pois os extents não são contíguos no espaço físico, tal como o não vão ser os blocos de dados.

• Para manter a contiguidade dos blocos de dados, o ideal é prever o espaço que a

tabela vai ocupar, e atribuir ao seu segmento o valor do primeiro extent. Esta atribuição assegura que os blocos de dados atribuídos à tabela permaneçam contíguos. A definição do valor do primeiro extent da tabela permite criar uma tabela que não vai ser fragmentada, tornando-se assim mais rápida a execução de querys e outras operações.


Parâmetros do comando CREATE TABLE • valor do primeiro extent da tabela é definido pelo parâmetro INITIAL do comando

CREATE TABLE. Apesar deste valor não poder ser alterado uma vez criada a tabela, o administrador pode definir o valor do próximo extent no segmento através do parâmetro NEXT do comando ALTER TABLE.

• O valor de PCTFREE determina a percentagem de espaço que fica livre em cada

bloco para as actualizações de dados.

- Os dados são armazenados nos blocos de uma forma contígua. - Após uma actualização a um dado já armazenado, este pode necessitar de mais

espaço do que ocupava antes da actualização.

- Toda a informação relativa a um determinado dado é sempre armazenada no mesmo bloco, mas se não existir espaço suficiente livre no bloco para efectuar uma actualização a um dado, o Oracle reorganiza os blocos de tal forma que os dados que estavam nesse bloco passem a ficar em dois blocos do mesmo extent, implicando isto a diminuição da velocidade de actualizações.

- O ideal, na determinação do valor do parâmetro PCTFREE é deixar livre em cada

bloco espaço suficiente para as actualizações aos dados que requerem mais espaço.

- O parâmetro PCTFREE determina a percentagem de espaço livre em cada bloco

que é deixada para actualizações. Quando esta percentagem for atingida, o bloco fica cheio e deixa de ser possível inserir novos dados no bloco.


• O parâmetro PCTUSED determina o nível a que o espaço livre tem de descer para voltar a ser possível inserir novos dados no bloco.

- Uma vez que o espaço livre no bloco de dados alcance o valor de PCTFREE, não

são inseridos novos registos no bloco até a percentagem de espaço utilizado chegar abaixo de PCTUSED.

- A percentagem de espaço utilizado no bloco altera-se à medida que são feitas

inserções ou apagamentos. O valor de PCTUSED deve ser calculado em função do espaço ocupado por cada registo e do valor de PCTFREE. A soma de PCTFREE e PCTUSED nunca pode ultrapassar 100.

- A diferença (100-PCTFREE-PCTUSED) corresponde ao espaço no bloco que fica

livre para processamento. Quando esta diferença é muito pequena, a eficiência no aproveitamento do espaço é melhor, mas piora o performance do processamento.

• É imprescindível determinar o valor ideal da soma de PCTFREE e PCTUSED para que

exista uma boa combinação ente a performance de I/O e a utilização de espaço. • A melhor forma de encontrar o valor ideal da soma PCTFREE e PCTUSED é fazer

com que a diferença ente PCTUSED e PCTFREE seja a percentagem do espaço médio ocupado por um registo no espaço total do bloco. Para este cálculo, deve ser considerado o tamanho do bloco que não é ocupado por overhead (cabeçalho, directoria de tabelas e directoria de registos).

Determinação do valor de PCTFREE • Uma tabela, em que são feitos poucas actualizações que aumentem o espaço

ocupado pelos registos, deve ter um PCTFREE baixo (2% a 5%). • Se o cenário é de actualizações frequentes que aumentam o espaço ocupado pelo

registo, então o PCTFREE deve ser alto (10% a 20%).


Cálculo do valor de INITIAL O parâmetro INITIAL determina o valor do primeiro extent da tabela a ser criada. O método para calcular este valor pode ser resumido nos cinco passos seguintes: 1. Calcular o espaço no bloco não ocupado pelo block header; 2. Calcular o espaço livre em cada bloco; 3. Calcular o espaço ocupado por cada registo; 4. Calcular o n.º de registos que cabem num bloco; 5. Calcular o n.º de blocos e bytes que a tabela vai ocupar. • 1º passo Calcular o espaço livre no bloco, que corresponde ao espaço do bloco que não é ocupado por headers (hespaço). O header é composto de uma parte variável e de uma parte fixa. Esta notação é simplificada, pois considera o header com sendo composto só de uma parte fixa. hespaço = DB_BLOCK_SIZE - KCBH - UB4 - KTBBH - (INITRANS -1) * KTBIT - KDBH DB_BLOCK_SIZE - corresponde ao tamanho de um bloco. Este valor pode ser encontrado executando um select à vista do sistema denominada de V$TYPE_SIZE.

(Na base de dados em estudo=2k ou 2048 bytes) KCBH, UB4, UB1, KTBBH, KTBIT e KDBH - são constantes cujos tamanhos podem ser obtidos através de uma consulta à vista do sistema V$TYPE_SIZE. (Na base de dados em estudo: KCBH = 20; UB4 = 4; KTBBH = 48; KTBIT = 24; KDBH = 14; KDBT = UB4; UB1 = 1; SB2 = 2). O INITRANS corresponde ao número de transacções concorrentes da tabela, sendo o seu valor por defeito é 1. (Na base de dados em estudo: INITRANS permanece com o seu valor por defeito.) hespaço = 2048 - 20 - 4 - 48 - (1 - 1 ) *24 - 14 = 1962


• 2º passo O espaço reservado para dados em cada bloco (espaçoliv), é calculado em função do valor de PCTFREE da respectiva tabela. A sua fórmula é a seguinte: espaçoliv = CEIL(hespaço * (1 - PCTFREE/100) - KDBT onde CEIL é uma função que arredonda um valor fraccionado ao valor inteiro acima do mesmo. Se for considerada a tabela FORNECEDOR, onde o valor de PCTFREE é de 10, então: espaçoliv = CEIL(1962 * (1-10/100) - 4 = CEIL(1962 * 0,9) -4 = 1762


• 3º passo Calcular a quantidade de espaço ocupado por cada registo é uma operação de múltiplas tarefas: a) Em primeiro lugar devem ser calculados os valores dos espaços médios ocupados

por cada coluna (tamanho_medio_coluna) e em seguida o somatório desses valores (tamanho_medio_registo). O tamanho_medio_coluna é um valor estimativo que pode ser calculado manualmente coluna a coluna. Se o ambiente, da base de dados teste, for semelhante ao da base de dados proposta então este calculo pode ser efectuado empiricamente através do seguinte comando em SQL:

tamanho_medio_registo = SELECT AVG(NVL(VSIZE(col1), 0) + AVG(NVL(VSIZE(col2), 0) + . . . + AVG(NVL(VSIZE(coln), 0) FROM nome_de_tabela; onde col1, col2 ... coln são os nomes das colunas existentes na tabela. Para a tabela FORNECEDOR foi executada a seguinte instrução para calcular o valor de tamanho_medio_registo: SELECT AVG(NVL(VSIZE(COD_FORN),0)) + AVG(NVL(VSIZE(FNOME),0)) + AVG(NVL(VSIZE(FMORADA),0))+ AVG(NVL(VSIZE(FLOCAL),0))+ AVG(NVL(VSIZE(C_POSTAL),0))+ AVG(NVL(VSIZE(FTELEF),0))+ AVG(NVL(VSIZE(FFAX),0))+ AVG(NVL(VSIZE(FEMAIL),0))+ AVG(NVL(VSIZE(FCONTACTO),0))+ AVG(NVL(VSIZE(FN_CONTRIB),0)) FROM FORNECEDOR; O resultado obtido para tamanho_medio_registo foi 131.


• 3º passo b) Na próxima etapa, é necessário calcular o tamanho do registo com o byte length

(tamanho_byte_length), adicionando o valor do byte length a cada coluna.

tamanho_medio_coluna com byte length = tamanho_medio_coluna + (se o tamanho_medio_coluna <250, então 1, senão 3)

Como nenhuma das colunas da tabela FORNECEDOR excede 250 bytes, então é necessário adicionar um byte para cada coluna. Como a tabela fornecedor contém 10 colunas então, tamanho_byte_length = tamanho_medio_registo + (10 * 1) = 131 + 10 = 141 Finalmente o espaço médio do registo (tamanho_médio) é calculado com a fórmula, tamanho_médio = row header + tamanho_byte_length = (3 * UB1) + 141 = (3 * 1) + 141 = 144 c) Por fim o espaço ocupado pelo registo (espaço_registo) é calculado com a

fórmula, espaço_registo = MAX ((UB1 * 3 + UB4 + SB2), tamanho_médio) + SB2 = MAX ((1 * 3 + 4 + 2), 144) + 2 = MAX (9, 144) + 2 = 146 Como se observa através desta fórmula, o espaço ocupado por um registo nunca pode ser menos de 11 bytes.


• 4º Passo Para calcular o número de registos que podem ser colocados num bloco de dados (num_registos_bloco) pode ser utilizada a seguinte fórmula: num_registos_bloco = FLOOR (espaçoliv / espaço_registo) FLOOR é aqui uma função que arredonda o valor fraccionado ao valor inteiro abaixo do mesmo. Para a tabela FORNECEDOR: num_registos_bloco = FLOOR (1762 / 146 ) = FLOOR (12,06) = 12 • 5º passo Uma vez calculado o valor de num_registos_bloco, deve ser feita uma estimativa de quantos registos a tabela vai ocupar (est_registos). Para a base de dados em estudo foi estimado que a tabela FORNECEDOR iria ocupar 500 registos nos próximos cinco anos. est_registos = 500 Após a estimativa do número de registos, o número de blocos ocupados pela tabela (blocos_por_tabela) pode então ser calculado. A fórmula para este cálculo é: blocos_por_tabela = est_registos / num_registos_bloco Para a tabela FORNECEDOR: blocos_por_tabela = 500 / 12 = 41,6 = 42 blocos bytes_por_tabela = blocos_por_tabela * 2048 = 42 * 2048 = 86016 bytes • Depois de criada uma tabela, o espaço requerido pela mesma é normalmente maior

do que o valor estimado nos cálculos acima referidos. Este acréscimo deve-se ao facto de o Oracle, ao gerir a base de dados, precisar de espaço livre para processamento. É então aconselhável adicionar 10% ao valor de bytes que a tabela ocupa para definir o valor de INITIAL.

Valor de INITIAL da tabela FORNECEDOR = 86016 * 1.10 = 94618


Cálculo do valor de PCTUSED Para determinar os valores óptimos para os parâmetros, a diferença entre PCTUSED e PCTFREE deve ser a percentagem de espaço livre que cada registo ocupa no bloco (percentagem_registo). A fórmula abaixo descrita utiliza as variáveis espaçoliv e tamanho_médio, que já foram descritas, para calcular o valor percentagem_registo. percentagem_registo = CEIL(espaço_registo / hespaço) Na tabela FORNECEDOR, este valor é calculado da seguinte forma: percentagem_registo = CEIL(146/1962) = 8% Um registo da tabela FORNECEDOR ocupa 8 % do espaço livre no bloco. Como o valor de PCTFREE da tabela FORNECEDOR é 10 então, o valor de PCTUSED pode ser calculado resolvendo a seguinte equação: 100- (PCTUSED + PCTFREE) = percentagem_registo 100 - (PCTUSED + 10) = 8 PCTUSED = 82 então: PCTUSED = 100 - PCTFREE - CEIL(espaço_registo / hespaço) Comando de criação de uma tabela CREATE TABLE FORNECEDOR (COD_FORN NUMBER(4) PRIMARY KEY, FNOME VARCHAR2(45) NOT NULL, FMORADA VARCHAR2(45), FLOCAL VARCHAR2(20), C_POSTAL NUMBER(4), FTELEF VARCHAR2(20), FFAX VARCHAR2(20), FEMAIL VARCHAR2(45), FCONTACTO VARCHAR2(45), FN_CONTRIB NUMBER(10) UNIQUE, FOREIGN KEY (C_POSTAL) REFERENCES CODPOSTAL (C_POSTAL)) PCTUSED 82 PCTFREE 10 STORAGE(INITIAL 94618);


XI. Estruturas Facultativas para melhorar pesquisas Índices • Estruturas facultativas associadas a colunas de tabelas ou agrupamentos de tabelas

e destinadas a acelerar o acesso aos dados; • Índices são o equivalente a um índice de um livro, pois permitem localizar

rapidamente a informação pretendida. Criação e gestão de Índices (oracle) índices são: - lógica e fisicamente independentes dos dados da tabelas a que estão associados

⟨ a criação / apagamento de índices não interfere com os dados da tabela nem com a estrutura da base de dados;

- criados pelo utilizador através de comandos SQL

ex: CREATE INDEX nome_artigo ON Artigo(anome); - geridos automaticamente pelo sistema

Em cada consulta (select) numa tabela com índice(s) associado(s) o sistema decide se usa ou não o índice para aceder aos dados;

A inserção, actualizarão e/ou apagamento de dados na tabela leva a que o

sistema actualize de maneira transparente para o utilizador, o(s) índice(s) dessa tabela;

O facto de uma tabela ter índices não leva a qualquer alteração nos comandos

DML sobre essa tabela.


Cornando para criação de um índice CREATE INDEX nome_artigo ON Artigo(anome) TABLESPACE users STORAGE (INITIAL 20K

NEXT 20K PCTINCREASE 75 PCTFREE 0);

- Cria o índice nome_artigo sobre a coluna Anome da tabela Artigo.

- O índice pode ficar num tablespace diferente do da tabela (isso até tem a vantagem

de melhorar a velocidade).

- Ao criar o índice pode definir-se os parâmetros de armazenamento, que

determinam como vai ser atribuído espaço (extents) para o segmento do índice.

Para criar um índice é preciso ter privilégios de INDEX e quota no tablespace usado (se for diferente do por defeito) Estrutura interna de um índice Os índices são armazenados como B*-trees


Como funciona a pesquisa em tabelas com índice? (ideia geral) SELECT * FROM Empregados Where nome ='Lemos';

O sistema começa por usar o índice para determinar o ROWID do registo pretendido. Depois usa o ROWID para encontrar o registo. índices compostos (concatenados) Um índice pode ser criado sobre mais do que uma coluna da tabela: Exemplo: CREATE INDEX Art_id ON Artigo(cod_grupo, cod_familia, cod_artigo);


Criação implícita de índices - Ao definir uma chave primária a coluna (ou colunas) que constituem essa chave

são automaticamente indexadas; - Idem para colunas com restrição UNIQUE (chaves candidatas). Índices UNIQUE/NON_UNIQUE Ao criar um índice pode-se indicar se ele é do tipo UNIQUE ou NON_UNIQUE: - UNIQUE garantem que as colunas indexadas são sempre unívocas. - NON_UNIQUE não garantem univocidade (índices para colunas duplicadas são

ordenados na B*-Tree) Não se deve usar os índices para reforçar restrições de integridade UNIQUE. Estas devem ser declaradas explicitamente. \ Que tabelas se devem indexar ? - Tabelas grandes (com muitos registos); - Tabelas em que as pesquisas sejam muito específicas (devolvam uma percentagem

pequena de registos; e.g. <10%); - Tabelas relativamente estáticas em que a principal operação é a pesquisa e as

operações de escritas são pouco frequentes (notar que as operações de escrita ficam mais lentas pois o sistema tem que tratar da manutenção do índice após cada operação).


Que colunas se devem indexar ? - Colunas sobre as quais as aplicações fazem muitas pesquisas; - Chaves forasteiras para acelerar as junções (notar que as chaves primárias já estão

indexadas); - Colunas em que a maioria dos valores são distintos (eg. não faz muito sentido

indexar a coluna relativa ao sexo numa tabela de funcionámos); - Colunas com uma gama de valores vasta; - Colunas com muitos valores nulos mas em que a maioria das pesquisas procura

apenas entre os valores não nulos. Nota: Não se pode indexar colunas do tipo LONG e LONG RAW. Quando é que se deve indexar uma tabela ? • Pode-se criar um índice em qualquer altura da existência de uma tabela mas a

melhor altura é depois da tabela já conter muitos dados. • Notar que se cria o índice quando a tabela ainda está vazia então a inserção de

dados fica mais lenta pois o sistema tem de rearranjar a B*-Tree do índice com relativa frequência.

Quantos índices pode haver por cada tabela ? Pode haver qualquer número de índices por tabela, mas não esquecer que quantos mais índices houver mais lentas ficarão as operações de Insert, Update e Delete, pois é necessário manter mais B*-Trees (uma para cada índice).


Ordem das colunas na criação dos Índices Exemplo: Artigo_Lojas (IDArtigo, IDLoja, Preço, Quantidade) Supor que: - A tabela pode ter algumas dezenas de lojas, mas que cada loja (IDLoja) pode ter

milhares de artigos (IDArtigo); - Há consultas frequentes do tipo Select * From. Artigo_Lojas Where IDArtigo = 1243 And IDLoja = 8; Nesse caso o índice a criar deveria indicar primeiro a coluna com mais valores distintos (IDArtigo). CREATE INDEX Artigo_id ON Artigo_Lojas(IDArtigo, IDLoja); Nota: Excluindo os aspectos relativos à velocidade a ordem das colunas poderia ser uma qualquer. Eliminar índices DROP INDEX Artigo_Loja; - A eliminação de um índice não altera a base de dados; só afecta a velocidade a que

as operações passam a ser realizadas; - Quando se elimina uma tabela todos os índices a ela associados também são

eliminados.


Agrupamentos (clusters) • Grupo de tabelas que partilham os mesmos blocos (mesmo segmento) porque

contêm colunas que são frequentemente usadas em conjunto; • Os agrupamentos são facultativos (quem decide da sua criação e que tabelas vão

entrar no agrupamento é o programador); • Os agrupamentos são explicitamente criados pelo programador; • Uma vez criado um agrupamento a sua gestão fica a cargo do sistema; • Os agrupamentos não interferem com o esquema lógico da base de dados. Tabelas agrupadas (clusters) Tabelas agrupadas - são armazenadas no mesmo cluster.

CODPOSTAL LOCALIDADE 1000 Lisboa

COD_FORN NOME_FORN1 J.J.&Filhos4 InforPaper

4000 PortoCOD_FORN NOME_FORN2 Copiconta Lda

3000 CoimbraCOD_FORN NOME_FORN3 MacInfo Lda

...........


Tabelas não agrupadas - Cada tabela tem o seu segmento, que pode ser composto por extents afastados uns dos outros tornando as junções lentas.


...........

FORNECEDORCOD_FORN NOME_FORN CODPOSTAL1 J.J.&Filhos 10002 Copiconta Lda 40003 MacInfo Lda 30004 InforPaper 1000

...........

Vantagens dos agrupamentos





...........

Chave de agrupamentoCluster key

• Melhor velocidade nas junções (pois ambas as tabelas partilham os mesmos

blocos); • Melhor aproveitamento de espaço (pois os valores da(s) coluna(s) em comum são

armazenados apenas uma vez, independentemente do número de vezes que aparecem nas tabelas).


Criação de agrupamentos CREATE CLUSTER Forn_Post (Codpostal number(4))

PCTUSED 80 PCTFREE 5 SIZE 600 TABLESPACE USER STORAGE (INITIAL 200K

NEXT 300K MINEXTENTS 20 MAXEXTENTS 20 PCTINCREASE 30);

Uma vez definidos estes parametros no cluster, a definição de parâmetros similares nas tabelas não tem efeito. CREATE TABLE Fomecedor (

Cod_forn number(4), .... CLUSTER Forn_Post (Codpostal);

CREATE TABLE Cod_Postal

.... CLUSTER Fom _ Post (Codpostal);

As tabelas só podem ser criadas depois do cluster.


O parâmetro SIZE Estimativa do espaço necessário (em média) para guardar uma chave do agrupamento e os registos a ela associados;

CODPOSTAL LOCALIDADE

1000 LisboaCOD_FORN NOME_FORN1 J.J.&Filhos4 InforPaper



...........

Utilizado pelo Oracle para limitar o número de chaves de agrupamento que podem ser atribuídas a um dado bloco (e armazenadas no bloco); Escolha de SIZE Importante fazer uma boa estimativa do tamanho médio da chave do agrupamento e registos a ela associados; Má escolha de SIZE: - SIZE demasiado pequeno

a velocidade baixa pois é necessário reorganizar os dados nos blocos com maior frequência

- SIZE demasiado grande

o aproveitamento do espaço é pobre.


Índices de agrupamentos (cluster index) • Depois de se criar um agrupamento tem sempre de se criar um índice sobre a

coluna ou colunas que formam a chave do agrupamento; • Permite encontrar mais rapidamente a chave do agrupamento que aponta para um

dado bloco de dados associado a esse valor da chave:





...........

Coluna de índice deagrupamento

Só é possível usar o agrupamento se for criado um índice sobre a chave do agrupamento. Criação de índices de agrupamentos CREATE INDEX Forn_Post_Indice ON CLUSTER Forn_Post TABLESPACE USER STORAGE (INITIAL 50K

NEXT 50K MINEXTENTS 2 MAXEXTENTS 10 PCTINCREASE 30 PCTFREE 5);

Só depois de criado o índice é que se pode inserir dados nas tabelas do agrupamento.


Características de índices de agrupamentos Tal como os índices das tabelas: - É criado e armazenado num segmento de índice; - É gerido pelo sistema. Ao contrário dos índices, das tabelas: - É obrigatório para se poder aceder aos dados; - Têm de ser criados antes do agrupamento ter dados; - Valores nulos da chave do agrupamento também têm uma entrada no índice do

agrupamento; - O índice do agrupamento só tem entradas para os valores da chave do

agrupamento e não para todos os registos do agrupamento; - Quando o índice do agrupamento é eliminado os dados deixam de estar

disponíveis até que novo índice seja criado. Que tabelas agrupar? - As tabelas devem ser usadas essencialmente para pesquisas (i.e., uma vez

preenchidas as tabelas deixa de haver novas inserções. Notar que isto é condição necessária para ser possível estimar o parâmetro SIZE);

- As tabelas devem ser acedidas maioritariamente através de Junções; - Se as tabelas forem acedidas individualmente com muita frequência então não se

devem agrupar (como cada bloco contém agora dados de mais do que uma tabela são necessários mais blocos, pelo que o acesso individual fica mais lento).

Que colunas para chave do agrupamento ? - A coluna ou colunas usadas nas junções; - Colunas em que a maioria dos valores são distintos

(se a coluna ou colunas usadas nas junções não tiverem estas características então é melhor usar clusters);

- Colunas com uma gama de valores vasta; - Colunas que só raramente são actualizadas.


Alterar agrupamentos É possível alterar seguintes parâmetros de um agrupamento já existente: - parâmetros de utilização de espaço nos blocos (PCTFREE, PCTUSED); - tamanho médio da chave do agrupamento (SIZE); - parâmetros de atribuição de extents (NEXT, PCTINCREASE, etc.). Eliminar e tabelas e agrupamentos DROP CLUSTER Forn_Post INCLUDING TABLES;

Elimina tudo: o agrupamento as tabelas nele contidas e o índice do agrupamento. Não é possível eliminar o agrupamento sem eliminar as tabelas.

- A eliminação individual de tabelas no agrupamento não afecta o resto das tabelas

no agrupamento (que continuam agrupadas) nem o índice do agrupamento;


Hashing • Armazenar uma tabela num hash cluster é uma alternativa a armazenar a mesma

tabela com um índice; • A utilização de hashíng tem (também) por objectivo melhorar a velocidade a que

os dados são encontrados e armazenados. Armazenamento dos dados num hash cluster

Representação lógica do hash cluster

Chavede hash

Chave deagrupamento

outras colunas

COD_FORN120 1230 ........

1020 ........1200 ........1233 ........

121 1022 ........1334 ........1213 ........

...........

Tabela em Hash Cluster

Objectivo do hash cluster: encontrar o registo pretendido num único acesso a disco.

FORNECEDORCOD_FORN NOME_FORN CODPOSTAL1 J.J.&Filhos 10002 Copiconta Lda 40003 MacInfo Lda 30004 InforPaper 1000

...........

Tabela + Índice

Índice

A tabela e o índice estão guardados em segmentos diferentes, pelo que qualquer pesquisa necessita de pelo menos 2 acessos a disco.


Hashing. âmbito de utilização Pesquisa: sequência de comparações de chaves até se encontrar a chave pesquisada ou se concluir que essa chave não existe. Válido para: - pesquisa sequencial; - pesquisa binária; - pesquisa sequencial com reordenamento; - pesquisas em árvore; - etc. Situação ideal: Não ter comparações desnecessárias; a chave ser acedida num único acesso. Exemplo de pesquisa directa - uma tabela sobre fornecedores é armazenada num array; - que a tabela nunca teria mais do que 100 registos; - que cada fornecedor é identificado por um número de dois dígitos.

01 02 03 04 05 ..... 97 98 99

0 número de fornecedor pode ser usado como índice do array, pelo que encontrar um fornecedor corresponde a um único acesso. Não há comparações desnecessárias. Mesmo que existam menos de 100 fornecedores, em muitas situações o desperdício em espaço e compensado pelo acesso directo.


Função de hash Na maioria dos casos não é possível utilizar a chave como índices do array. Por exemplo: Base de dados até 100 fornecedores em que cada fornecedor é identificado por um número de 7 dígitos. Solução: Converter a chave num índice.

Índices COD_FORN outras colunas0 437620012 8760502 ........

97 ........98 ........99 5342799 ........

...........

h(chave) é o índice da tabela, ou o hash da "chave" Ex: h(6543697) = 97 h(chave)=chave mod 100 Colisões de hash Problema: Pode acontecer que h(chave1) h(chave2) É necessário: - minimizar as colisões de hash ⇐ aumentando a gama de valores da função de

hash - Resolver as colisões de hash, quando elas surgirem

por endereçamento aberto por encadeamento


Encontrar um registo num único acesso SELECT .... FROM FORNECEDOR WHERE COD_FORN = 1022;


Chavede hash

Chave deagrupamento

outras colunas

COD_FORN120 1230 ........

1020 ........1200 ........1233 ........

121 1022 ........1334 ........1213 ........

...........


O sistema faz:

hash(1022)=121

DATA_BLOCK_ROW_FILE

Aplicando a função de hash sobre a número de fornecedor pretendido (e fazendo mais *alguns cálculos simples) o sistema obtém o ROWID do registo, pelo que acede directamente ao registo pretendido. Número de valores de hash Controlado pelo> parâmetro HASHKEY, que é definido no momento da criação do hash cluster, HASHKEY elevado - minimiza colisões; boa velocidade; - mau aproveitamento do espaço atribuído ao hash cluster. HASHKEY baixo - pode levar a muitas colisões resolver colisões e reorganizar blocos, pelo que a

velocidade é afectada.


O parâmetro SIZE de um hash cluster Estimativa do espaço necessário (em média) para guardar os registos associados a uma chave de hash;


Chavede hash

Chave deagrupamento

outras colunas

COD_FORN120 1230 ........

1020 ........1200 ........1233 ........

121 1022 ........1334 ........1213 ........

...........


Utilizado pelo Oracle para determinar o número de chaves de hash associadas a cada bloco (cujos registos associados são armazenadas no bloco); A escolha de SIZE segue os mesmos critérios definidos para agrupamentos (clusters). Determinação de parâmetros importantes Exemplo 1: Tabela Fornecedor (Cod_forn,... Número máximo de registos (estimado) = 2000 Tamanho médio de cada registo 100 bytes Hash key: Cod_forn SIM 100 HASHKEYS 2000 Exemplo 2: Tabelas Departam (NDept, ..... ) e Empregados (Nemp, . . NDept) Número máximo de departamentos (estimado) = 100 Número médio de empregados por departamento = 10 Tamanho médio de cada registo (empregado) = 55 bytes Hash key: NDept SIZE = 55 * 10 = 5 50 -> 600 HASHKEYS = 100


Criar um hash cluster CREATE CLUSTER Forn_cluster (Cod_forn NUMBER(7)) PCTUSED 80 PCTFREE 5 TABLESPACE users STORAGE (INITIAL 250K NEXT 50K MINEXTENTS 1 MAXEXTENTS 3 PCTINCREASE 0) SIZE 2K HASH IS Cod_forn HASHKEYS 150; CREATE TABLE Fornecedor (Cod_forn NUMBER(7) PRIMARY KEY, CLUSTER Forn cluster (Cod forn) Quando é que se deve armazenar uma tabela num hash cluster? Quando a condição definida para a pesquisas tem igualdade: SELECT ......FROM tabela WHERE Chave-de-cluster Outras características referidas para o caso dos clusters simples; Como qualquer cluster (agrupamento), um hash cluster pode conter diversas: tabelas, quando estas são acedidas frequentemente através de junções.

teoria sobre bases de dados relacionais · teoria sobre sistemas de gestão de bases de dados 1 i....

Documents