bd - aspectos basicos

Aspectos Bsicos de

Banco de Dados

Prof. Rogrio Gonalves Bittencourt, M.Sc.

Florianpolis, fevereiro de 2004.

ASPECTOS BSICOS DE BANCO DE DADOS i

Copyright 2004. Adobe Acrobat eBookReader for Windows. Todos os direitos reservados. O contedo deste livro somente para informao e est sujeito a correes sem avisos. Nenhuma parte deste livro pode ser reproduzida ou transmitida, em qualquer forma ou em qualquer meio, eletrnico, gravao mecnica, ou qualquer outro, sem uma permisso por escrito do autor. Por favor, lembre-se que a arte existente ou imagens que voc pode querer incluir em seu projeto podem ser protegidas pela lei de direitos autorais. A incorporao de tal material em seu trabalho sem autorizao poderia ser uma violao dos direitos autorais. Por favor, esteja certo de obter permisso do autor.

ASPECTOS BSICOS DE BANCO DE DADOS i

Contedo

INTRODUO 1

Qual a Diferena Entre Dados, Informao e Conhecimento 1

Banco de Dados 1

Sistema de Gerncia de Banco de Dados (SGBD) 2

Sistema de Banco de Dados 2

Porque Usar Banco de Dados 4

Vantagens do Controle Centralizado 4

O Que se Pode Almejar Com o Uso de SBD 5

Modelos de Dados 6

Arquitetura de um SGBD 6

Os Trs Nveis da Arquitetura 7

Nvel Externo 10

Nvel Conceitual 12

Nvel Interno 13

Mapeamentos 14

Linguagens de SGBDs 14

Independncia de Dados 16

Administrador de Banco de Dados 16

Exerccios 19

MODELOS DE DADOS (MODELOS CONCEITUAIS E LGICOS) 21

Classificao de Modelos de Dados 21

Modelos Lgicos Baseados Em Objetos 21

ASPECTOS BSICOS DE BANCO DE DADOS ii

Modelos Lgicos Baseados Em Registro 21

Modelos Fsicos de Dados 25

Classificao de SGBDs 25

Exerccios 25

MODELO RELACIONAL 27

Dicionrio de Dados 30

Tabelas de Exemplo do Dicionrio de Dados 31

Regras de Integridade Relacional 32

Implicaes das Regras 33

Especificao de Banco de Dados Relacional 33

As 12 Regras de Codd 34

INTEGRIDADE 43

Controle de Integridade Semntica do Banco de Dados 43

Classificao dos Requisitos de Integridade (RI) 45

Mtodos Utilizados no Suporte Especificao de Restries de Integridade 47

Definio e Teste de Restries de Integridade 47

Exemplo de Manuteno de Restrio de Integridade Com e Sem TRIGGER (SQL) 48

Triggers Podem Causar Problemas 49

Tcnicas Para a Implementao de Controle Automtico de RIs no SGBD 50

Vantagens do Esquema Pr-Compilativo 50

VISES 53

Vantagens 55

Algumas Sugestes Importantes 55

TRIGGERS 56

ASPECTOS BSICOS DE BANCO DE DADOS iii

Vantagens 57

Utilizao de Triggers 57

ASPECTOS BSICOS DE BANCO DE DADOS 1Introduo

Introduo Neste captulo apresentaremos alguns termos (terminologia) e

conceitos de grande importncia.

Qual a Diferena Entre Dados, Informao e Conhecimento

DADOS - representao de fatos, conceitos ou instrues de maneiras formalizadas, adequadas para comunicao, interpretao ou processamento por pessoas ou meios automatizados.

INFORMAO - significado que pessoas associam aos dados atravs de convenes usadas em sua interpretao.

CONHECIMENTO - discernimento, critrio, apreciao prtica de vida, experincia.

Banco de Dados

Um banco de dados um conjunto de arquivos relacionados entre si (Chu, 1983)

Um banco de dados uma coleo de dados operacionais armazenados, sendo usados pelos sistemas de

aplicao de uma determinada organizao (C. J. Date, 1985)

Um banco de dados uma coleo de dados relacionais (Elmasri & Navathe, 1989)

Um banco de dados um conjunto de dados armazenados, cujo contedo informativo representa, a cada

instante, o estado atual de uma determinada aplicao (Laender, 1990)


Baseado nas definies acima se pode deduzir ento que Banco de Dados :

Coleo de dados relacionados; Coleo logicamente coerente de dados com algum significado

inerente; Um BD est sempre associado a aplicaes e a usurios que tm

interesse nele.

Ex: Agenda de endereos

Sistema de Gerncia de Banco de Dados (SGBD)

O SGBD permite a definio, construo e manipulao do banco de dados para diversas aplicaes.

DEFINIO do BD: Envolve a especificao dos tipos de dados a serem armazenados no BD, mais a descrio de cada tipo de dado.

CONSTRUO do BD: Processo de armazenar os dados em um meio controlado pelo SGBD.

MANIPULAO do BD: Execuo de operaes de consulta e recuperao de dados especficos, alm de atualizao de dados para refletir, no BD, mudanas no mini-mundo sendo modelado. A manipulao inclui, tambm, a gerao de relatrios a partir dos dados do BD.

Sistema de Banco de Dados

Sistema de Banco de Dados um sistema de software composto pelos programas de aplicao, pelo SGBD e pelo BD, para um conjunto de aplicaes de uma mesma organizao.

Programas de aplicao, colocado na definio acima, so programas que realizam funes da aplicao. EX.: clculo das dedues e impostos, a partir da receita apurada, dos custos computados e da legislao em vigor. Eles tambm so os responsveis pela garantia das restries de integridade que no podem ser controladas pelo SGBD. Implementam interfaces e relatrios especficos. Acessam o BD atravs do SGBD para consulta e atualizao dos dados da aplicao.


Resumindo:

SBD = BD + SGBD + PA

De acordo com (DATE,1985), um SBD dividido em mdulos que tratam de partes, em separado, cada uma das responsabilidades do sistema geral. Estes componentes fundamentais so:

Gerenciador de Arquivos que trata da alocao do espao para armazenamento e das estruturas de dados utilizadas para representar a informao armazenada no disco;

Gerenciador de Banco de Dados fornece a interface entre os dados de baixo nvel armazenados no disco e os programas aplicativos e de consulta submetidos ao sistema;

Processador de Consultas traduz as consultas escritas em uma linguagem de alto nvel para instrues de baixo nvel que o gerenciador do banco de dados entende;

Pr-compilador DML converte comandos DML embutidos em um aplicativo para chamadas de procedimento normal na linguagem hospedeira;

Arquivos de Dados armazenam banco de dados por si mesmos; Dicionrio de Dados o componente responsvel pelo

armazenamento dos metadados sobre a estrutura do banco de dados. O dicionrio de dados bastante utilizado;

UsuriosIngnuos

Programadoresde aplicativos

Usuriossofisticados

Administrador debanco de dados

Interfaces doaplicativo

Programasaplicativos

Consulta Esquema debancos de

Gerenciadorde arquivos

Arquivosde dados

Dicionriosde dadosDISCO

Pr-compiladorda linguagem

de manipulaode dados

Compilador delinguagem de

definio de

Processadorde consultas

Gerenciadorde bancode dados

Cdigo objetode programas

aplicativos

SGDB


Porque Usar Banco de Dados

Sistema de Banco de Dados proporciona empresa o controle centralizado de seus dados operacionais. Tal situao contrasta nitidamente com o que podemos encontrar em uma empresa que no utiliza um SGBD, onde cada aplicao dispe de seus prprios arquivos de tal forma que os dados operacionais so muito dispersos, dificultando o controle sistemtico. Isto implica que exista um DBA, isto , um Administrador do Banco de Dados (Database Administrator, em ingls).

Vantagens do Controle Centralizado

Reduzir Redundncia Nos sistemas gerenciadores de arquivos, cada aplicao possui seus prprios arquivos. Este fato costuma provocar uma redundncia considervel nos dados armazenados, causando desperdcio de espao de armazenamento.

Evitar Inconsistncia A inconsistncia conseqncia natural da redundncia. Suponhamos que um certo fato do mundo real (o fato de que um fornecedor X fornece o item Y para a empresa) representado por duas entradas distintas no banco de dados, e que o SGBD no tenha conhecimento da duplicidade (redundncia no controlada). Ocorrer que em determinado momento duas entradas no so concordantes. Diz-se, ento, que o banco de dados inconsistente.

Compartilhamento dos Dados O compartilhamento no significa apenas que as aplicaes existentes podem compartilhar os dados do banco de dados, mas tambm que novas aplicaes podem ser desenvolvidas para operar sobre os mesmos dados armazenados.

Padronizao Pelo fato do controle centralizado, o SGBD pode assegurar que todos os padres aplicveis sero observados na representao dos dados.

Restries de Segurana O DBA (Adm. do Banco de Dados), detendo toda a autoridade sobre as dados operacionais, pode assegurar:

Que os nicos meios de acesso ao banco de dados sejam realizados atravs de certos canais;

Definir controles de segurana a adotar (principalmente para dados especiais);


Estabelecer diferentes controles para cada tipo de acesso (recuperao, modificao, anulao, etc.), e para cada parte da informao no banco de dados.

Manter a Integridade O problema da integridade assegurar que os dados do banco de dados sejam corretos (ntegros), ou seja, as informaes que compe o BD tm que expressar exatamente o que foi informado, o BD no pode permitir que as informaes se modifiquem incorretamente.

Integridade Referencial - os registros de relacionamentos devem fazer referncia a ocorrncias de entidades existentes no banco de dados. No deve haver relacionamento referenciando uma chave primria inexistente.

Integridade Transacional - as transaes efetuadas na base de dados devem ocorrer com segurana, completando-se ou no o procedimento, os dados devem se manter ntegros.

Equilibrar Necessidades Conflitantes O DBA, tendo conhecimento das necessidades globais da empresa (em oposio s necessidades de um usurio individual) pode estruturar o sistema, a fim de proporcionar um servio geral que seja o melhor para a empresa.

Independncia dos Dados Independncia de dados um dos objetivos de um SGBD, e consiste na capacidade de isolar programas de aplicao das mudanas em estruturas de armazenamento (esquema fsico), definio dos dados (esquema lgico) e das estratgias de acesso do BD. Um SGBD que oferea independncia de dados garante que programas continuem a rodar se os dados armazenados forem reorganizados para atender a outra aplicao prioritria. Aplicaes baseadas em sistemas de arquivos dependem dos dados.

O Que se Pode Almejar Com o Uso de SBD

Redundncia controlada de dados Compartilhamento de dados por aplicaes diversas Controle de autorizao de acesso a dados Acesso a dados atravs de diferentes interfaces Modelagem de relacionamentos complexos entre dados Garantia de restries de integridade da aplicao Garantia de consistncia fsica dos dados Potencial para imposio de padres (modelagem e

programao) Flexibilidade na definio e manuteno dos dados Reduo do tempo de desenvolvimento de aplicaes


Modelos de Dados

Conjunto de conceitos que podem ser usados para descrever o BD. Divide-se em Modelos Conceituais, Modelos de Implementao e Modelos Fsicos.

Modelos Conceituais: Provem conceitos prximos aos percebidos por muitos usurios. Usam conceitos como entidades, atributos e relacionamentos.

EX: Modelo ER, Modelo OO

Modelos de Implementao: Tem conceitos que podem ser entendidos pelos usurios e no esto muito distantes da maneira como os dados so organizados fisicamente. So usados freqentemente em SGBDs comerciais. Representam os dados usando estruturas de registro.

EX: Modelo Relacional, Modelo Rede, Modelo Hierrquico.

Modelos Fsicos: Descrevem como os dados so armazenados representando informao como formato de registros, ordenao de registros, mtodos de acesso.

Arquitetura de um SGBD

A arquitetura divide-se em trs nveis gerais:

Nvel Interno Mais prximo do armazenamento fsico, isto , relaciona-se com a forma como os dados so armazenados. Emprega-se o Modelo de Dados Fsico para descrever detalhes de armazenamento.

Nvel Conceitual Descreve a estrutura completa de um BD para uma comunidade de usurios. uma descrio global do BD, que esconde detalhes da estrutura fsica de armazenamento. Pode-se empregar um modelo de alto nvel (modelo conceitual) ou de implementao.

Nvel Externo Mais prximo dos usurios. formado por um conjunto de vises de usurios ou esquemas externos. Cada viso descreve a parte do BD que um grupo de usurios est interessado. Pode ser empregado um modelo de alto nvel (modelo conceitual) ou de implementao

A maioria dos SGBDs no separa os 3 nveis completamente. Alguns incluem detalhes de nvel fsico no nvel conceitual.


Notar que os 3 esquemas so apenas descries de dados. Os dados que realmente existem esto no nvel fsico.

Estamos agora prontos para delinearmos uma arquitetura para um sistema de banco de dados. Nosso propsito, ao apresentar esta arquitetura, estabelecer a base sobre a qual possamos trabalhar nos captulos subseqentes. Esta base extremamente til para descrevermos os conceitos gerais do banco de dados e explicarmos a estrutura de sistemas de banco de dados especficos - mas, certamente, no queremos afirmar que todo o sistema se encaixa nesta estruturao, nem sugerir que esta arquitetura, em particular, estabelece a nica base possvel. Os sistemas "pequenos" (com base em micro), especialmente, no suportaro todos os aspectos da arquitetura. Entretanto, parece que ela ajustase razoavelmente bem maioria dos sistemas (relacionais ou outros); ademais, em termos gerais, concorda com a proposio do "ANSI/SPARC Study Group on Data Base Management Systems" [2.1-2.4]. Optamos, contudo, por no seguir a terminologia ANSI/SPARC em todos os detalhes.

Os Trs Nveis da Arquitetura

A arquitetura divide-se em trs nveis gerais: interno, conceitual e externo. Em termos amplos:

O nvel interno o mais prximo ao armazenamento fsico - i.e. relaciona-se forma como so realmente armazenados os dados;

O nvel externo o mais prximo aos usurios - i.e., forma como os dados so vistos pelos usurios individuais;

O nvel conceitual o "nvel de simulao", entre os dois outros. Se o nvel externo diz respeito s vises do usurio individual, o nvel

conceitual pode ser considerado a viso do grupo de usurios.

Em outras palavras, haver muitas "vises externas" distintas, cada uma consistindo em uma representao mais ou menos abstrata de determinada parte do banco de dados e haver precisamente uma "viso conceitual", que corresponde representao abstrata do banco de dados em sua totalidade.' (Lembremo-nos que a maioria dos usurios no estar interessada em todo o banco de dados, mas somente numa parte restrita do mesmo.) Da mesma forma, haver exatamente uma "viso interna", representando todo o banco de dados como armazenado de fato.


viso 1 viso 2 viso n

Nvel Fsico

Nvel Conceitual

...Nvel externo (vises do usurio individual) Nvel conceitual (viso do conjunto de usurios) Nvel interno (viso do armazenamento)

Os trs nveis da arquitetura.

Um exemplo tornar estas idias mais claras. A figura seguinte mostra a viso conceitual de um simples banco de dados sobre funcionrios, a viso interna correspondente e as duas vises externas correspondentes, uma para um usurio de PL/1 e outra para o usurio de COBOL. O exemplo, na certa, totalmente hipottico - no pretende simular qualquer sistema real - e muitos detalhes irrelevantes foram deliberadamente omitidos. Veja os esquemas abaixo:

Externo (PL/1) Externo (COBOL) DCL 1 EMPP, 01 EMPC. 2 EMP # CHAR (6), 02 EMPNO PIC X (6) 2 SAL FIXED BIN (31) 02 DEPTNO PIC X (4).

Conceitual EMPLOYEE EMPLOYEE_NUMBER CHARACTER (6) DEPARTAMENT_NUMBER CHARACTER (4) SALARY NUMERIC (5) Interno STORED_EMP LENGTH = 118 PREFIX TYPE = BITE(6), OFFSET = O EMP# TYPE = BYTE(6), OFFSET = 6, INDEX = EMPX DEPT# TYPE = BYTE(4), OFFSET = 12 PAY TYPE = FULLWORD, OFFSET = 16

Exemplos dos trs nveis.

Interpretamos da seguinte maneira:

Banco de dados contm, no nvel conceitual, informaes referentes ao tipo de entidade chamada EMPLOYEE. Cada EMPLOYEE tem um EMPLOYEE-NUMBER (seis caracteres), um


DEPARTMENT-NUMBER (quatro caracteres) e um SALARY (cinco dgitos decimais).

Os funcionrios esto representados, no nvel interno, por um tipo de registro armazenado chamado STORED-EMP, com dezoito bytes de comprimento. O STORED-EMP contm quatro tipos de campos armazenados: um prefixo de seis bytes (contendo, provavelmente, informaes de controle como sinalizadores ou ponteiros), e trs campos de dados correspondendo s trs propriedades dos funcionrios' Os registros STORED_FMP so, adicionalmente, indexados no CAMPO EMP por um ndice chamado EMPX.

O usurio de PL/1 tem uma viso externa do banco de dados, na qual cada funcionrio representado por um registro PL/I, contendo dois campos (os nmeros de departamento no so do interesse deste usurio, e por isto foram omitidos da viso). O tipo de registro definido por uma declarao comum de estrutura PL/I, de acordo com as regras normais de PL/I.

Do mesmo modo, o usurio de COBOL tem uma viso externa, na qual cada funcionrio representado por um registro COBOL, contendo, novamente, dois campos (desta vez foi omitido o de salrio). O tipo de registro definido por um registro comum COBOL, de acordo com as regras normais do COBOL.

Observemos que objetos correspondentes podem ter nomes diferentes em cada nvel. O nmero do funcionrio, por exemplo, chamado de EMP# na viso da PL/I, e de EMPNO na viso COBOL, como EMPLOYEE-NUMBER na viso conceitual e como EMP # (novamente) na viso interna. O sistema certamente deve estar a par das correspondncias. Deve ser informado, por exemplo, que o campo COBOL EMPNO deriva do objeto conceitual EMPLOYEE-NUMBER que, por sua vez, representado no nvel interno pelo campo armazenado EMP#. Tais concordncias, ou mapeamentos, no so mostradas no esquema acima.

Observao: Em um sistema relacional o primeiro nvel, o nvel conceitual, ser definitivamente relacional, no sentido de que os objetos visveis neste nvel sero tabelas relacionais (os operadores tambm sero operadores relacionais, i.e., operadores que trabalham com tais tabelas). Uma determinada viso externa (segundo nvel, nvel externo) ser igualmente relacional ou algo bem prximo; por exemplo, os registros PL/1 e COBOL da Fig. 1.3 podem ser considerados, respectivamente, como as representaes PL/I e COBOL de (uma linha dentro de) uma tabela relacional. O terceiro nvel, o nvel interno, certamente no ser sempre relacional, desde que os objetos desse nvel no sero exatamente tabelas relacionais (armazenadas) - ao contrrio, sero a mesma espcie de objetos encontrados no nvel interno de outros tipos de sistema (a saber, registros armazenados, ponteiros, ndices, acessos hash etc.). De fato, a teoria


relacional como tal no tem nada a dizer sobre o nvel interno (repetimos, sobre como o banco de dados aparece para o usurio).

Examinaremos agora mais detalhadamente os trs nveis da arquitetura, iniciando com o nvel externo. A figura abaixo, qual estaremos nos referindo neste captulo, mostra os principais componentes da arquitetura e seus inter-relacionamentos.

Nvel Externo

O nvel externo o nvel do usurio individual. Um determinado usurio, como explicado no Captulo I, tanto pode ser um programador de aplicaes como um usurio de terminal on-line - i.e., um usurio final - de qualquer grau de sofisticao. O DBA um caso especial importante. (Ao contrrio dos usurios comuns, o DBA ter de se interessar pelos nveis conceitual e interno tambm. Vide as prximas duas sees.) Cada usurio tem uma linguagem sua disposio:

Esta linguagem, para o programador de aplicao, pode ser uma linguagem convencional de programao, como COBOL ou PL/I, ou uma linguagem de programao apropriada, especfica do sistema em questo (sistemas NOMAD, Rdv/VMS ou dbase II).

Para o usurio final, pode ser uma linguagem de consulta ou uma linguagem de propsitos especiais, talvez baseada em formulrios ou menu, modelada s necessidades do usurio e suportada por um programa de aplicao on-line.

Para nossos propsitos, o que importa sabermos que todas essas linguagens incluiro uma sublinguagem de dados - ou seja, um subconjunto de toda a linguagem, voltado para os objetivos e operaes do banco de dados. A sublinguagem de dados (abreviada na Fig. 2.3 como DSL) embutida na linguagem hospedeira correspondente, a qual proporciona os diversos recursos no-especficos de banco de dados, tais como variveis locais (temporrias), operaes computacionais, lgica if-then-else e assim por diante. Um determinado sistema pode suportar mltiplas linguagens hospedeiras e mltiplas sublinguagens de dados.

Observao: Embora seja conveniente diferenciar, na arquitetura, a sublinguagem de dados e linguagem hospedeira, as duas, em relao ao usurio, podem ser indistinguveis. Se assim for, ou se s puderem ser separadas com dificuldades, dizemos que so unidades de maneira firme. Se as linguagens so fceis e claramente separadas, dizemos que so "unidas de maneira indefinida". A maioria dos sistemas de hoje suporta apenas a unio indefinida. Um sistema firmemente unido propiciar um conjunto de recursos mais uniforme para o usurio, mas obviamente requer maior esforo por parte dos projetistas do


sistema (o que poderia explicar o que temos hoje). Entretanto, parece haver um movimento que, gradualmente, nos levar a dispor, nos prximos anos, de sistemas com unio mais firme.

Em princpio, qualquer sublinguagem de dados realmente uma combinao de pelo menos duas linguagens subordinadas: a linguagem de definio de dados (DDL), que possibilita a definio ou descrio dos objetos do banco de dados, e a linguagem de manipulao de dados (DML), que suporta a manipulao ou processamento desses objetos. Consideremos o usurio de PL/1 da Fig. 2.2 de Seo 2.2. A sublinguagem de dados para aquele usurio compe-se dos aspectos de PL/1 utilizados para a comunicao com o DBMS. A parte DDL consiste nas construes declarativas do PL/I necessrias para declarar os objetos do banco de dados: a prpria instruo DECLARE (DCL), certos tipos de dados PL/I, e possivelmente as extenses especiais para PL/I, para suportar novos objetos que no so tratados pelo PL/1 existente. A parte DML compe-se das instrues executveis do PL/I que transferem as informaes de e para o banco de dados - podendo, novamente, incluir novas instrues especiais. (Observao: Os PL/I atuais de fato no incluem aspectos especficos de banco de dados. As instrues "DML", por isto, so apenas "CHAMADAS" para o DBMS. Eis por que sistemas PL/I, como muitos sistemas atuais, s proporcionam uma unio muito indefinida entre a sublinguagem de dados e a hospedeira.)

Voltando arquitetura: J mencionamos que o usurio individual, por via de regra, s vai interessar-se por determinada parte do banco de dados; alm disso, a viso que o usurio ter daquela parcela , em geral, algo abstrato, em comparao forma como os dados so fisicamente armazenados. Em termos ANSI/SPARC, a viso de determina do usurio uma viso externa. A viso externa , portanto, o contedo do banco de dados como visto por determinado usurio (ou seja, para aquele usurio, a viso externa o banco de dados). Um usurio d Departamento de Pessoal, por exemplo, pode ver o banco de dados como uma coleo de eventos de registros do departamento, e uma coleo de eventos de registros de empregados (podendo estar totalmente desinformado das ocorrncias de registros de fornecedores e peas vistas pelos usurios do Departamento de Compras).

Portanto, uma viso externa consiste, em geral, em ocorrncias mltiplas, de mltiplos tipos de registro externo'. Um registro externo no necessariamente o mesmo que um registro armazenado. A sublinguagem de dados do usurio definida em termos de registros externos; por exemplo, uma operao de recuperao de registro da DML ir recuperar um evento de registro externo, e no uma ocorrncia de registro armazenado.

Cada viso externa definida por meio de um esquema externo, que consiste, basicamente, em definies para cada um dos vrios tipos de registro externo naquela viso externa. O esquema externo descrito


usando-se a parte DDL da sublinguagem de dados do usurio. (Denomina-se, assim, a DDL, s vezes, de DDL externa.) O tipo de registro externo funcionrio, por exemplo, pode ser definido como um campo de seis caracteres, nmero do funcionrio, mais um campo de cinco dgitos decimais, 'salrio', e assim por diante. Alm disso, deve haver uma definio do mapeamento entre o esquema externo e o esquema conceitual fundamental (descrito na prxima seo).

Voltamo-nos agora para o nvel conceitual.

Nvel Conceitual

A viso conceitual a representao de todo o contedo de informaes do banco de dados, tambm (como a viso externa) um tanto abstrato quando comparada forma como os dados so fisicamente armazenados, que tambm pode ser bem diferente da maneira como os dados so vistos por qualquer usurio em particular. A grosso modo, podemos dizer que a viso conceitual a viso dos dados "como realmente so", e no como os usurios so forados a v-los devido s restries (por exemplo) da linguagem ou do hardware utilizados pelos mesmos.

A viso conceitual consiste em ocorrncias mltiplas de tipos mltiplos de registros conceituais. A mesma pode consistir, por exemplo, em uma srie de ocorrncias de registros de departamentos, mais um conjunto de ocorrncias de registros de funcionrios, ou de fornecedores de peas ... De um lado, um registro conceitual no necessariamente o mesmo do que um registro externo e, de outro, nem o mesmo que um registro armazenado.

A viso conceitual definida pelo esquema conceitual que inclui definies de todos os diversos tipos de registros conceituais. O esquema conceitual escrito atravs de outra linguagem de definio de dados, a DDL conceitual. Para que se possa alcanar a independncia de dados, essas definies da DDL conceitual no podem conter quaisquer consideraes sobre a estrutura de armazenamento ou a estratgia de acesso - devem ser apenas definies das informaes. Assim, no pode haver referncia ao esquema conceitual para as representaes do campo armazenado, seqncia de registro armazenado, indexao, acesso hash, ponteiros ou quaisquer outros detalhes de armazenamento/acesso. Se o esquema conceitual for realmente independente de dados, ento os esquemas externos, que so definidos em termos do esquema conceitual, tambm sero necessariamente independentes de dados.

A viso conceitual, ento, a viso do contedo total do banco de dados, e o esquema conceitual uma definio desta viso. Seria errado, porm, dizer-se que o esquema conceitual no nada mais do que um conjunto de definies parecidas com simples definies de registros como encontrados, por exemplo, num programa COBOL. As definies no esquema conceitual devem incluir uma grande quantidade de aspectos, como controles de segurana e de integridade. Algumas autoridades na


matria ainda vo mais alm, e sugerem que o objetivo final do esquema conceitual descrever toda a empresa - no somente os dados operacionais, mas tambm como so usados: como transcorre o fluxo em cada ponto da empresa, como usado em cada ponto, como se aplicam auditoria ou outros controles em cada ponto, e assim por diante [2.5]. Enfatizamos, no entanto, que hoje em dia nenhum sistema realmente suporta um nvel conceitual que se aproxime deste grau de abrangncia; na maioria dos sistemas existentes, o esquema conceitual realmente pouco mais que uma simples unio de todos os esquemas externos e individuais, com a provvel adio de alguns controles de segurana e integridade. Mas tudo indica que os sistemas, no futuro, sero eventualmente mais sofisticados quanto ao suporte do nvel conceitual.

Nvel Interno

O terceiro nvel da arquitetura o nvel interno. A viso interna uma pequena representao de todo o banco de dados; consiste em ocorrncias mltiplas de tipos mltiplos de registros internos. O "registro interno" termo ANSI/SPARC para a estrutura que temos denominado de registro armazenado (termo que continuaremos a empregar). A viso interna um tanto distante do nvel fsico, uma vez que no trabalha em termos de registros fsicos (tambm chamados pginas ou blocos), nem de consideraes de dispositivos especficos tais como cilindro ou comprimento de trilha. (A viso interna assume basicamente um espao de endereamento linear e infinito. Os detalhes de como este espao de endereamento mapeado at o armazenamento fsico so altamente especficos a cada sistema, e deliberadamente omitidos de arquitetura).

A viso interna descrita por meio do esquema interno, que no s define os vrios tipos de registros armazenados como tambm especifica os ndices que existem, como os campos armazenados so representados, a seqncia fsica dos registros armazenados, e assim por diante. O esquema interno preparado atravs de uma outra linguagem de definio de dados - a DDL interna.

Observao: Nesse livro, usaremos normalmente o termo "banco de dados armazenado" em vez de viso interna, e o termo definio de estrutura de armazenamento em vez de esquema interno.

Observamos, parte, que, em certas situaes excepcionais, os programas de aplicao - em particular, as aplicaes de natureza "utilitria" - podem operar diretamente no nvel interno, ao invs do nvel externo. No necessrio dizer que esta prtica no recomendvel; representa um risco de segurana (posto que o controle de segurana no observado) e um risco de integridade (uma vez que os controles de integridade tambm no so observados), e o programa, alm disso, torna-se dependente de dados, em algumas ocasies, porm esta poder ser a nica forma de se obter a funo ou a performance necessria - assim


como o usurio de uma linguagem de programao de alto nvel pode, ocasionalmente, precisar utilizar a linguagem de montagem (assembler) para satisfazer certos objetivos funcionais ou de desempenho.

Mapeamentos

O leitor poder observar dois nveis de mapeamento na arquitetura, um entre os nveis externo e conceitual do sistema e um entre os nveis conceitual e interno. O mapeamento conceitual interno define a correspondncia entre a viso conceitual e o banco de dados armazenado; especifica como os registros e campos conceituais so representados no nvel interno. Se a estrutura do banco de dados armazenado for modificada - i.e., se for executada uma mudana na definio da estrutura armazenada -, o mapeamento conceitual/interno tambm dever ser modificado de acordo, de forma que o esquema conceitual permanea invarivel. (O controle destas mudanas da responsabilidade do DBA.) Em outras palavras, os efeitos dessas modificaes devem ser isolados abaixo do nvel conceitual, de maneira a preservar a independncia de dados.

Um mapeamento externo conceitual define a correspondncia entre uma determinada viso externa e a viso conceitual. As diferenas que podem existir entre estes dois nveis so similares quelas que podem existir entre a viso conceitual e o banco de dados armazenado. Como exemplo, os campos podem ter tipos de dados diferentes, as denominaes de campo e registro podem ser modificadas, campos conceituais mltiplos podem ser combinados num nico campo externo (virtual) etc. Pode haver qualquer nmero de vises externas ao mesmo tempo; qualquer quantidade de usurios pode compartilhar de uma determinada viso externa; diferentes vises externas podem sobrepor-se. Alguns sistemas possibilitam que a definio de uma viso externa seja expressa em termos de outra (de fato, via mapeamento externo/externo), ao invs de exigirem sempre uma definio explcita do mapeamento a nvel conceitual - um aspecto muito til, quando diversas vises externas se relacionam entre si.

Linguagens de SGBDs

A linguagem de SGBD's essencialmente SQL, que por sua vez subdividido em grupos de comandos, de acordo com a funo de cada comando. Infelizmente, estas subdivises no so utilizadas por todas as implementaes de SGBD's. Elas so enfatizadas pela ANSI (American National Standards Institute), mas muitos produtos SQL no as tratam separadamente na prtica.

A Linguagem de Definio de Dados (ou DDL - Data Definition Language, ou tambm chamado pela ANSI como Linguagem de Definio de Esquema) consiste nos comandos que criam os objetos (tabelas, ndices,


vises, e assim por diante) no banco de dados. Linguagem de Manipulao de Dados (DML - Data Manipulation Language) um conjunto de comandos que determinam quais valores esto presentes nas tabelas em qualquer momento. A Linguagem de Controle de Dados (DCL - Data Control Language) consiste nas caractersticas que determinam se a um usurio permitido executar uma ao particular. Isto considerado parte da DDL pela ANSI. Elas (DDL, DML e DCL) no so linguagens diferentes por si s, mas divises de comandos SQL em grupos de acordo com suas funes.

Ento, resumindo,

DDL = Data Definition Language - Linguagem de definio de dados, possibilita a definio ou descrio dos objetos do BD.

DML = Data Manipulation Language - Linguagem de manipulao de dados, que suporta manipulao (acesso e alterao).

DCL = Data Control Language - Linguagem de controle de dados, possibilita a determinao das permisses que cada usurio ter sobre os objetos do BD (permisso de criao, consulta, alterao, etc.).

No SQL, por exemplo, so instrues DML:

SELECT - consulta (seleo)

UPDATE - atualizao

DELETE - excluso

INSERT - incluso

DMLs podem ser:

procedurais - o usurio tem que especificar o que deseja e como pretende obter isso. Recuperam registros individuais do BD e processam cada registro separadamente. (devem ser embutidas em LPGs)

no procedurais - so capazes de expressar operaes complexas de maneira concisa. O usurio especifica apenas o que deseja, e permite que o sistema decida como obter isso. (pode ser embutida em uma LPG de propsito geral)


Independncia de Dados

O Banco de Dados pode ser visto sob trs nveis de abstrao:

Nvel Fsico nvel mais baixo de abstrao, descreve como os dados esto realmente armazenados. Complexas estruturas de dados de baixo nvel so descritas em detalhes.

Nvel Conceitual descreve quais dados esto armazenados de fato no BD e as relaes que existem entre eles. Aqui o BD inteiro descrito em termos de um pequeno nmero de estruturas relativamente simples.

Nvel Visual o mais alto nvel de abstrao descreve apenas parte do BD. Apesar do uso de estruturas mais simples do que no nvel conceitual, alguma complexidade perdura devido ao grande tamanho do BD.

A habilidade de modificar a definio de um esquema em um nvel sem afetar a definio de esquema num nvel mais alto chamada de independncia de dados. Existem dois nveis de independncia de dados:

Independncia fsica de dados a habilidade de modificar o esquema fsico sem a necessidade de rescrever os programas aplicativos. As modificaes no nvel fsico so ocasionalmente necessrias para aprimorar o desempenho.

Independncia lgica de dados a habilidade de modificar o esquema conceitual sem a necessidade de rescrever os programas aplicativos. As modificaes no nvel conceitual so necessrias quando a estrutura lgica do BD alterada.

Administrador de Banco de Dados

Uma das principais razes para empregar um SGBD ter um controle central dos dados e dos programas de acesso a eles. A pessoa que tem esse controle sobre o sistema chamada administrador do banco de dados (DBA). O administrador do banco de dados (DBA) a pessoa (ou grupo de pessoas) responsvel pelo controle do sistema. As responsabilidades do DBA incluem o seguinte:

Decidir o contedo de informaes do banco de dados Faz parte do trabalho do DBA decidir exatamente que informao manter no banco de dados - em outras palavras, deve identificar as entidades do interesse da empresa e a informao a registrar em relao a estas entidades.' Uma vez feito isto, o DBA deve ento definir o contedo do banco de dados, descrevendo o esquema conceitual (usando o DDL conceitual). A forma objeto (compilado) daquele esquema


utilizada pelo DBMS para responder s solicitaes de acesso. A forma (no compilada) atua como documento de referncia para os usurios do sistema.

Decidir a estrutura de armazenamento e a estratgia de acesso O DBA tambm deve decidir como os dados sero representados no banco de dados', e definir esta representao escrevendo a definio da estrutura de armazenamento (usando a DDL interna). Alm disso, deve definir o mapeamento associado entre os nveis interno e conceitual. Na prtica, tanto a DDL conceitual quanto a DDL interna - mais provavelmente a primeira - provavelmente incluiro os meios de definio desse mapeamento, mas as duas funes (a definio do esquema, a definio do mapeamento) devem ser claramente separadas. Tal como o esquema conceitual, o esquema interno e o mapeamento correspondente existiro no s na forma fonte como na forma objeto.

Servir de elo de ligao com usurios funo do DBA servir de elo de ligao com os usurios, a fim de garantir a disponibilidade dos dados de que estes necessitam, e preparar - ou auxili-los na preparao dos necessrios esquemas externos, utilizando a DDL externa apropriada (como j mencionamos, um determinado sistema pode suportar diversas DDLs externas e distintas). E, ainda, tambm deve ser definido o mapeamento entre qualquer esquema externo e o esquema conceitual. Na prtica, a DDL externa provavelmente incluir os meios de especificao do mapeamento, mas o esquema e o mapeamento devem ser claramente separados. Cada esquema externo e o mapeamento correspondente existiro tanto na forma fonte como na forma objeto.

Definir os controles de segurana e integridade Os controles de segurana e de integridade, como j mencionado, podem ser considerados parte do esquema conceitual. A DDL conceitual incluir os recursos para a especificao de tais controles. a Definir a estratgia de reserva e recuperao. A partir do momento em que a empresa comea efetivamente a basear-se em banco de dados, torna-se dependente do bom funcionamento deste sistema. Na eventualidade de danos parte do banco de dados - causados, digamos, por erro humano, ou por falha no hardware, ou no sistema operacional de suporte -, de suma importncia fazer retornar os dados envolvidos com um mnimo de demora e com as menores conseqncias ao restante do sistema. Por exemplo, os dados que no sofreram danos no devero ser afetados.' O DBA deve definir e implementar uma estratgia de recuperao apropriada envolvendo, por exemplo, o descarregamento


peridico do banco de dados na memria auxiliar de armazenamento e procedimentos para recarreg-lo, quando necessrio.

Monitorar o desempenho e atender as necessidades de modificaes O DBA deve organizar o sistema de tal maneira que obtenha o melhor desempenho para a empresa; e efetuar os ajustes adequados quanto s necessidades de modificaes. Como j mencionamos, quaisquer mudanas nos detalhes de armazenamento e acesso devem ser acompanhadas de mudanas correspondentes na definio do mapeamento, a partir do nvel conceitual, de forma que o esquema conceitual possa permanecer constante. O DBA precisa de diversos programas utilitrios que o auxiliem nas tarefas de administrao do BD. Estes so uma parte essencial de um sistema de banco de dados prtico, embora no sejam mostrados na Fig. 1.3 da arquitetura. Abaixo esto alguns exemplos dos programas utilitrios necessrios.

Rotinas de Carga Para criar uma verso inicial do banco de dados a partir de um ou mais arquivos.

Rotinas de Despejo na Memria e Recuperao Despejar o banco de dados, auxiliar de armazenamento de dados, e recarregar o banco de dados a partir dessa cpia de segurana. Observao: As rotinas de carga mencionadas acima consistiro, na prtica, no aspecto de "recuperao" das rotinas de despejo/recuperao na memria.

Rotinas de Reorganizao Para rearrumar os dados no banco de dados, em vista de diversas razes de desempenho - por exemplo, agrupar os dados de certa maneira ou regenerar espao ocupado por dados que se tornaram obsoletos.

Rotinas Estatsticas Para computar diversos desempenhos estatsticos, tamanhos de arquivos e distribuio de valores de dados.

Rotinas Analticas Para analisar as estatsticas mencionadas. Uma das ferramentas mais importantes do DBA - de muitas maneiras e, de fato, o corao de todo o sistema - o dicionrio de dados (conhecido tambm como catlogo do sistema). O dicionrio de dados pode ser considerado um banco de dados, um banco de dados de sistema. O contedo do dicionrio pode ser considerado "dados sobre dados" (s vezes denominado metadados) - ou


seja, descries de outros objetos no sistema, ao invs de simples "dados em bruto".

Exerccios

1) Quais so os principais componentes dos sistemas de BD? Explique sucintamente a funcionalidade de cada uma.

2) Defina os termos: 3) Banco de Dados 4) Sistemas de Gerncia de Bancos de Dados 5) Sistemas de Banco de Dados 6) Cite e explique algumas vantagens do uso de BD. 7) O que Integridade Referencial e Transacional? 8) O que Independncia de Dados? 9) Descreva a arquitetura de SBD de 3 nveis. 10) Quais so os tipos de linguagens de SGBD? Para que serve

cada uma? 11) Qual a diferena entre Independncia Fsica e Lgica? 12) Cite e explique algumas responsabilidades do DBA.

ASPECTOS BSICOS DE BANCO DE DADOS 21 Modelos de Dados

MODELOS DE DADOS (MODELOS CONCEITUAIS E LGICOS)

Uma Coleo de ferramentas conceituais para descrio de dados, relacionamentos de dados, semntica de dados e restries de consistncia.

Classificao de Modelos de Dados

Os vrios modelos de dados propostos atualmente, e encontrados na literatura, podem ser divididos em trs (3) grandes grupos: modelos lgicos baseados em objetos (= Modelos Conceituais), modelos lgicos baseados em registros (= Modelos Lgicos ou Modelos de Implementao) e, modelos fsicos de dados.

Modelos Lgicos Baseados Em Objetos - Modelos Conceituais

So usados na descrio de dados nos nveis conceitual e visual. Caracterizam-se pelo fato de fornecerem, de forma conveniente, capacidade de estruturao flexvel e admitem restries de dados para serem explicitamente especificados. Os mais conhecidos so:

Modelo Entidade-Relacionamento (MER);

Modelo Orientado a Objetos

O Modelo ER tem ganhado aceitao no projeto de BD e bastante utilizado na prtica.

O Modelo OO inclui muito dos conceitos no modelo ER, mas representa cdigos executveis assim como dados.

Modelos Lgicos Baseados Em Registro - Modelos Lgicos Ou De Implementao

So usados na descrio de dados nos nveis conceitual e visual. Em comparao aos modelos de dados baseados em objetos, ambos so usados para especificar a estrutura lgica geral do banco de dados e para fornecer uma descrio de alto nvel da implementao.


So assim chamados porque o BD estruturado em registros de formato fixo de diversos tipos. Cada tipo de registro define um nmero fixo de campos (atributos), e cada campo usualmente de um tamanho fixo.

Desde o final dos anos 60, vrios SGBDs comerciais foram construdos........

Os trs modelos mais aceitos so:

Modelo Relacional; Modelo Rede; Modelo Hierrquico.

Modelo Relacional

O Modelo Relacional representa dados e relacionamentos entre dados por um conjunto de tabelas, cada uma tendo um nmero de colunas com nomes nicos. Veremos o Modelo Relacional com mais detalhes mais adiante.

nome rua cidade nmero Ana Arvoredo Porto Alegre 900 Joo Norte So Paulo 556 Joo Norte So Paulo 647 Carlos Alameda Florianpolis 801 Carlos Alameda Florianpolis 647

nmero saldo 900 55 556 100.000 647 105.366 801 10533

Modelo Rede

Os dados no Modelo Rede, tambm conhecido como Modelo CODASYL ou DBTG, so representados por colees de registros (como no Pascal ou PL/I), e os relacionamentos entre os dados so representados por elos, que podem ser vistos como ponteiros. Os registros no BD so organizados como colees de grficos arbitrrios.

Um banco de dados rede consiste em uma coleo de registros que so conectados uns aos outros por meio de ligaes. Um registro em muitos aspectos similar a uma entidade no modelo ER. Cada registro uma coleo de campos (atributos), cada um dos quais contendo apenas um


valor de dado. Uma ligao uma associao entre precisamente dois registros. Assim, uma ligao pode ser vista como uma forma restrita (binria) de relacionamento no modelo ER.

Existem dois conceitos bsicos de estruturas:

registro (record type), onde cada registro descreve a estrutura de um grupo de registros que armazenaram o mesmo tipo de informao;

ligao pai-filho (set type), onde cada ligao pai-filho um relacionamento um-para-muitos (1:n) entre dois record types.

Cada registro representa alguma informao do mundo real sobre um grupo de itens, chamados itens de dados (ou atributos).

A figura abaixo mostra record types ESTUDANTE e CURSO, e um set type SE_MATRICULA entre eles, com ESTUDANTE como o registro-pai e CURSO como registro-filho. A representao diagramtica mostra o uso de uma seta do registro pai para o registro filho, chamada de DIAGRAMA DE BACHMAN, pois foi Charles Bachman que primeiro introduziu isto.

O conjunto de ocorrncias inclui o registro-pai JOO e trs registros-filhos correspondendo aos trs cursos nos quais ele se matriculou. Um banco de dados pode conter muitas ocorrncias da ligao pai-filho SE_MATRICULA, um por estudante. Note que se um estudante no associado em qualquer curso, a ocorrncia do registro ESTUDANTE ainda define um conjunto de ocorrncias na qual existe um registro-pai e zero registros-filhos. A figura mostra os itens de dados contidos nos registros acima mencionados.

Sistemas de banco de dados rede permitem vetores, que so itens de dados que podem ter valores mltiplos dentro de um registro. Isto corresponde a um atributo multivalorado no modelo ER.

Porto AlegreArvoredoAna

So PauloNorteJoo

FlorianpolisAlamedaCarlos

556

647

801

900

105.366

10.533

100.000

55

Exemplo de esquema de BD em rede BATINI, 1992


Modelo Hierrquico

O primeiro SGBD comercialmente disponvel e que se tornou popular era hierrquico, o BD da IBM, conhecido como IMS (Information Management System), que esteve no seu auge na dcada de 70. Como resultado, hoje existe uma grande base de dados que ainda utilizam a abordagem hierrquica.

O modelo hierrquico possui dois conceitos bsicos de estruturas:

Registro (record types), que definido como um grupo de registros que armazenam informaes de um mesmo tipo (no IMS, chamado de segmento);

Relacionamento pai-filho (parent-child relationship types), tambm chamado PCR type , um relacionamento um-para-muitos entre um segmento-pai e um segmento-filho.

Um segmento (record type) possui muitas ocorrncias, chamados registros. Uma ocorrncia de um PCR consiste de um registro do segmento-pai e muitos (zero ou mais) ocorrncias de um segmento-filho.

Um esquema de um BD hierrquico possui um nmero de hierarquias, onde cada hierarquia (esquema hierrquico) consiste de um nmero de segmentos e PCRs arranjados de maneira que forma uma rvore. A figura 2.4 mostra um esquema hierrquico com 2 segmentos e 1 PCR. Os PCRs so referidos como o par (segmento-pai, segmento-filho). Um registro pode somente possuir um segmento-pai. A figura mostra um possvel estado de um BD IMS.

Porto AlegreArvoredoAna

So PauloNorteJoo

FlorianpolisAlamedaCarlos

556 647

801900

105.366

10.533

100.000

55 647 105.366

Esquema de um BD hierrquico Heuser, 1995


Modelos Fsicos de Dados

So usados para descrever dados no nvel mais baixo. Existem poucos modelo fsicos em uso. Dois dos mais conhecidos:

Modelo Unificador; Estrutura de Memria.

Modelos Fsicos de dados capturam aspectos da implementao de sistemas de BD.

Classificao de SGBDs

Quanto ao modelo de dados (principal critrio):

Relacional representa o BD como coleo de tabelas; Hierrquico representa o BD um conjunto de rvores; Rede representa o BD como um grafo; Outros OO, relacional extendido, semntico,...

Quanto ao nmero de usurios:

mono-usurio; multi-usurio.

Quanto distribuio dos dados e software:

centralizado; distribudo.

Quando o SGBD distribudo e multi-usurio, cada usurio percebe o BD como se ele fosse mono-usurio e centralizado (conceito de transparncia em Sistemas Distribudos).

Exerccios

1) Defina Modelo de Dados. 2) Como so classificados os Modelos de Dados?

ASPECTOS BSICOS DE BANCO DE DADOS 27 Modelo Relacional

Modelo Relacional

Durante o perodo problemtico dos modelos hierrquico e rede, Edward F. Codd (1970) props o MODELO RELACIONAL. A partir da, diversas implementaes de Bancos de Dados Relacionais (RDBS - SGBDR) comearam a aparecer.

Os Bancos de Dados Relacionais possuem diversas caractersticas importantes que resolvem muitos dos problemas dos outros modelos (hierrquico e rede). Ao contrrio de seus antecessores, o Modelo Relacional no se baseia num paradigma de estruturao de dados particular, e sim em um fundamento matemtico especfico.

A viso de Banco de Dados mudou para um nvel mais alto, concentrando seus princpios no modelo de negcios e no na implementao de estruturas complexas.

O Modelo Relacional representa o BD como uma coleo de relaes. Informalmente, uma relao uma tabela ou arquivo simples.

.......................................

.........

.......................................

.........

LondonParis

Domniosos

COD NOME CIDADE 001 Smith London 002 Jones Paris 003 Adams Paris

Relao

Atributos Tupla

Chave Primria

Domnio

A noo de domnio de um item de dado assemelha-se noo de domnio de um conjunto na matemtica. Um Domnio D um conjunto de valores atmicos (indivisveis). o universo de valores permitido para um dado conjunto. Para tanto, necessrio o uso da DDL e da DCL do SGBD. Ainda, a definio de um domnio acarreta em certas operaes e comparaes de valor vlidas para um item de dado.

Domnios podem ser simples, ou seja, possuem um nico valor, como um inteiro, ou compostos, quando possuem vrios valores, como uma data, que apresenta dia, ms e ano. Os valores dos itens de dados que


apresentam domnios compostos so abstrados e tratados como um nico valor. Uma data poderia ser manipulada como uma string, por exemplo.

O Domnio especifica o tipo do atributo:

inteiros reais conjunto de cidades etc.

Atributo

Um Atributo representa o uso de um Domnio dentro de uma Relao. Vrios Atributos podem pertencer a um mesmo Domnio.

Matematicamente, um atributo o nome de um conjunto. Em uma tabela, representa uma coluna. Um atributo pode apresentar um valor condizente com o domnio associado a ele ou null. Null indica ausncia de valor ou valor desconhecido.

Relao

Uma Relao dos Domnios D1, D2, ..., Dn compe-se de:

um conjunto fixo de atributos (esquema da relao) A1, A2, ..., An, de forma que cada atributo Ai ( i = 1, 2, ..., n) corresponda exatamente a um dos domnios bsicos Di (colunas da tabela).

um conjunto de tuplas (linhas da tabela) Uma relao vista como uma tabela no modelo relacional,

composta por um cabealho e um corpo. O cabealho formado por um conjunto fixo de atributos que possuem nomes distintos, para evitar ambigidade na localizao de um item de dado.

Uma Relao possui uma Cardinalidade (= nmero de tuplas, = linhas) e um Grau (= nmero de atributos, = colunas).

O conceito de relao ligeiramente diferente do conceito de tabela. Relao equivale noo de conjunto, ou seja, um agrupamento de elementos sem repetio. Tabela equivale a noo de coleo, ou seja, um agrupamento de elementos onde permitida a repetio. SGBD's lidam, na prtica, com o conceito de tabela.

Uma relao r do esquema R(A1, A2, ..., An) um conjunto de tuplas r={t1, t2, ..., tn}, cada tupla uma lista de n valores t= onde cada valor vi ( i = 1, 2, ..., n) um elemento do domnio dom(Ai) ou um valor nulo especial.


Ex.: ESTUDANTE

Matrcula Nome Endereo 01 N1 E1 t1 ------ ------ Null t2 ... ... ... ... ------ ------ ------ tn

t1 = 01 dom (matrcula) N1 dom (nome) E1 dom (endereo)

Chaves

O conceito de chaves fundamental, pois permitem a identificao de tuplas em uma tabela, e permitem o estabelecimento de relacionamentos entre tabelas.

Tipos de Chaves:

Chave Primria Atributo ou combinao de atributos que permite a identificao nica de uma tupla em uma relao. uma ou mais colunas cujos valores distinguem uma linha das demais dentro de uma tabela. Uma chave primria no tem nenhuma ligao com a ordenao e com o acesso tabela, pois, segundo CODD, declarar um atributo como chave primria e acessar a tabela por outro atributo, serve para manter duas restries de integridade (vamos ver este conceito mais adiante).

Chave Candidata Em uma tabela, podemos identificar vrias alternativas de identificador nico, ou seja, vrios atributos ou combinaes de atributos que permitem a identificao nica de uma tupla em uma relao. Estas chaves seriam vrias chaves candidatas a serem chave primria. Toda chave primria uma chave candidata, porm nem toda chave candidata chave primria.

Chave Alternativa Do conjunto de chaves candidatas escolhemos somente uma para ser chave primria, as outras so chamadas de chaves alternativas.

Chave Estrangeira Atributo ou combinao de atributos de uma relao que so chaves primrias de outra relao. uma coluna ou combinao de colunas, cujos valores aparecem necessariamente na chave primria de uma tabela. A chave estrangeira o mecanismo que permite a implementao de relacionamentos em um BD Relacional.

Ex.: FUNCIONRIO (COD#, FNOME, DEPT#, SALARIO)

DEPARTAMENTO (DEPTNUM, DEPTNOME)


ndices

Permitem a otimizao da recuperao de tuplas em uma tabela, via um mtodo de acesso. um recurso fsico, cujo principal objetivo est relacionado com a performance do sistema. Cada estrutura de ndice est associada a uma chave de pesquisa particular.

Uma chave pode ser utilizada como ndice, porm um ndice no necessariamente uma chave. Existem vrios tipos de ndice (que dependem do ambiente relacional que estamos trabalhando):

ndices Primrios se um arquivo for organizado seqencialmente, isto , um arquivo seqencial, o ndice que possui uma chave de pesquisa que especifica esta ordem seqencial, chamado de ndice primrio. A chave de pesquisa de um ndice primrio geralmente a chave primria. Os arquivos que so organizados em ordem seqencial e possuem um ndice primrio, so chamados de arquivos seqenciais-indexados.

ndices Secundrios so os outros ndices que possuem uma chave de pesquisa, e esta chave de pesquisa no especifica a ordem seqencial do arquivo.

Dicionrio de Dados

A estrutura de um banco de dados relacional armazenada em um dicionrio de dados ou catlogo do sistema. O dicionrio de dados composto de um conjunto de relaes, idnticas em propriedades s relaes utilizadas para armazenar dados. Elas podem ser consultadas com as mesmas ferramentas utilizadas para consultar relaes de tratamento de dados. Nenhum usurio pode modificar as tabelas de dicionrio de dados diretamente. Entretanto, os comandos da linguagem de manipulao de dados que criam e destroem os elementos estruturais do banco de dados trabalham para modificar as linhas em tabelas de dicionrios de dados.

Em geral, voc encontrar os seguintes tipos de informaes em um dicionrio de dados:

Definio de colunas que compe cada tabela; Restrio de integridade imposta sobre relaes; As informaes de segurana (qual o usurio tem o direito de

realizar o qual operao sobre qual tabela);

Definies de outros elementos estruturais de um banco de dados, como visualizaes e domnios definidos pelo usurio;


Quando um usurio e tentar acessar dados de qualquer maneira, um SGBD relacional primeiro dirige-se ao dicionrio de dados para determinar se os elementos do banco de dados que o usurio solicitou fazem realmente parte do esquema. Alm disso, o SGBD verifica se o usurio tem os direitos de acesso quilo que ele est solicitando.

Quando um usurio tenta modificar dados, o SGBD tambm vai para o dicionrio de dados afins de procurar restries de integridade que podem ter sido colocadas na relao. Se os dados atendem s restries, a modificao permitida. Caso contrrio, o SGBD retorna uma mensagem de erro e no faz a alterao.

Como todo acesso ao banco de dados relacional feita atravs do dicionrio de dados, dizemos que os SGBD's relacionais so baseados em um dicionrio de dados.

Tabelas de Exemplo do Dicionrio de Dados

As tabelas precisas que compe um dicionrio de dados dependem um pouco do SGBD. Nesta seo, voc ver um exemplo de uma maneira tpica em que um SGBD especfico (SYBASE SQL ANYWHERE) organiza seu dicionrio de dados.

O fecho do dicionrio de dados realmente uma tabela que documenta todas as tabelas do dicionrio de dados. A partir dos nomes das tabelas do dicionrio de dados, voc provavelmente pode adivinhar que h tabelas para armazenar dados sobre tabelas bsicas, suas colunas, seus ndices e suas chaves estrangeiras.

creator tname dbspace tabletype ncols Primary key SYS SYSTABLE SYSTEM TABLE 12 Y

SYS SYSCOLUMN SYSTEM TABLE 14 Y

SYS SYSINDEX SYSTEM TABLE 8 Y

SYS SYSIXCOL SYSTEM TABLE 5 Y

SYS SYSFOREIGNKEY SYSTEM TABLE 8 Y

SYS SYSFKCOL SYSTEM TABLE 4 Y

SYS SYSFILE SYSTEM TABLE 3 Y

SYS SYSDOMAIN SYSTEM TABLE 4 Y

SYS SYSUSERPERM SYSTEM TABLE 10 Y

SYS SYSTABLEPERM SYSTEM TABLE 11 Y

SYS SYSCOLPERM SYSTEM TABLE 6 Y


A tabela syscatalog descreve as colunas em cada tabela (incluindo as tabelas do dicionrio de banco de dados). Na figura anterior, voc pode ver uma parte de uma tabela syscolumns que descreve a tabela de itens de vendas da Lasers Only.

creator cname tname coltype nulls lenth InPrymaryKey colno

DBA item_numb itens integer N 4 Y 1 DBA title itens varchar Y 60 N 2 DBA distributor-numb itens integer Y 4 N 3 DBA release_date itens date Y 6 N 4 DBA retail_price itens numeric Y 6 N 5

Lembre-se sempre de que essas tabelas de dicionrio de dados tm a mesma estrutura e deve obedecer s mesmas regras que as tabelas bsicas. Elas devem ter chave primria nica no-nula e tambm devem por integridade referencial entre elas prprias.

Regras de Integridade Relacional

Integridade da Entidade Integridade Referencial

As duas regras referem-se s chaves primrias e s chaves estrangeiras.

Regra de Integridade da Entidade:

Nenhum atributo de uma chave primria pode ter valor nulo.

Regra de Integridade Referencial:

Todas as chaves estrangeiras presentes em uma relao s podem ter valor igual a algum valor na relao onde ela chave primria.

Por exemplo, vamos supor o seguinte Diagrama ER:

CLIENTE AGNCIADEPSITO(1,n) (1,n)

NOMECLI

RUA

CIDADECLI

CONTANUM SALDO

NOMEAG

CIDADEAG

ATIVOS

Este diagrama geraria as seguintes tabelas:


NOMECLI RUA CIDADECLI NOMEAG JOO XYZ WWWWW DOWN CARLOS XXX WWWWW MIANUS SILVA XXX WWWWW MIANUS

CLIENTE

NOMEAG CIDADEAG ATIVOS DOWN YYYYYY 1000000 REDWOOD ZZZZZZZZ 5000000 MIANUS WWWWW 8000000

AGNCIA

NOMECLI NOMEAG CONTANUM SALDO JOAO DOWN 155123 2000120,00 JOAO REDWOOD 134556 255613,00 CARLOS MIANUS 111111 125842,00 SILVA MIANUS 548123 456982,00

DEPSITO

Implicaes das Regras

1) O SGBD deve rejeitar uma operao que torne o BD no ntegro, ou;

2) O SGBD deve aceitar a operao, mas realizar outras operaes compensatrias (se necessrio).

Especificao de Banco de Dados Relacional

A especificao de uma base de dados relacional (chamada de esquema da base de dados) deve conter no mnimo a definio do seguinte:

Tabelas que formam a base de dados Colunas que as tabelas possuem Restries de integridade

Abaixo mostrado o esquema correspondente s tabelas:


CODEMP NOME CODDEP CATEGFUNC ...... ...... ...... ...... ...... ...... ...... ......

EMP (CODEMP, NOME, CODDEP, CATEGFUNC)

CODDEP referencia DEPT

CODDEP NOME ...... ...... ...... ......

DEP (CODDEP, NOME)

Nesta notao, so listadas as tabelas e, para cada tabela, enumerados, entre parnteses, os nomes das colunas que compe a tabela. As colunas que compe a chave primria aparecem sublinhadas. Aps a definio da tabela aparecem as definies das chaves estrangeiras que aparecem na tabela na forma:

referencia

Ou, quando tratar-se de uma chave estrangeira composta por mltiplas colunas:

(1, 2, ....) referencia

As 12 Regras de Codd

Em outubro de 1985, E. F. Codd publicou uma srie de dois artigos no semanrio da indstria de computao chamado COMPUTER WORLD. O primeiro artigo delimitava 12 critrios a que um banco de dados relacional deve obedecer integralmente. O segundo artigo comparava os atuais produtos para mainframes com esses 12 critrios, produzindo uma srie de controvrsias sobre se os SGBD's devem ser teoricamente rigorosos ou se eles simplesmente devem trabalhar eficientemente.

Raros so os Bancos de Dados que se enquadrem em mais do que 10 destas regras.

As regras de Codd so:

Regra 1: as regras para informaes


"Toda as informaes em um banco de dados relacional so representadas explicitamente no nvel lgico e exatamente de uma maneira - por valores em tabelas.

O primeiro critrio para bancos de dados Relacionais lida com a estrutura de dados que so utilizadas para armazenar dados e representar relacionamentos de dados. O objetivo dessa regra fazer com que as relaes (e tabelas de dimensionar esse) sejam as nicas estruturas de dados utilizadas em um banco de dados relacional. Portanto, produtos que requerem links codificados diretamente entre tabelas no so relacionais. A linha Independentemente de da sua posio com relao a esse argumento em particular h duas razes importantes por que uma boa idia criar um banco de dados e com nada alm de tabelas.

Relacionamentos lgicos so muito flexveis. Em uma rede simples ou em um banco de dados hierrquico, os nicos relacionamentos que podem ser utilizados na recuperao so aqueles que foram predeterminados pelo projetista de banco de dados e que escreveu o esquema. Entretanto, uma vez que um banco de dados Relacional representa seus relacionamentos e por meio da correspondncia com valores de dados, a operao de join pode ser utilizada para implementar relaes instantaneamente, mesmo quelas que um projetista de banco de dados talvez no tenha antecipado.

Esquemas de banco de dados relacional so bem flexveis. Voc pode adicionar, modificar em remover relaes individuais sem afetar o restante do esquema. O fato, contanto que no alterem a estrutura de tabelas que atualmente est sendo utilizada, voc pode modificar o esquema de um banco de dados ao vivo. Entretanto, para modificar o esquema de uma rede simples o de um banco de dados e hierrquico, preciso interromper todo o processamento do banco de dados e gerar novamente o todo o esquema. Em muitos casos, modificar o projeto de banco de dados tambm significa recriar todos os arquivos fsicos (utilizando um processo de dump) para corresponder com o novo projeto.

Quando Codd originalmente escreveu suas regras, os bancos de dados no poderiam armazenar imagens. Hoje em dia, vrios SGBD's oferecem a opo de ir armazenar imagens como BLOBs dentro do banco de dados ou como nomes de caminho ou OVFLS para arquivos de imagens que so armazenados fora do banco de dados. Tecnicamente, nomes de caminho ou URLS para arquivos externos so ponteiros para algo alm de tabelas e, portanto, aparentemente fariam com que um SGBD viola-se essa regra. Entretanto, o esprito da regra que relacionamentos entre entidades - os relacionamentos lgicos no banco de dados - so representados


correspondendo valores de dados, sem o uso de ponteiros de qualquer tipo para indicar conexes entre entidades.

Regra 2: a regra de acesso garantido

"Cada e todos os dados (valor atmico) em um banco de dados relacional tm a garantia de serem logicamente acessveis pela reclassificao de uma combinao de nomes de tabelas, valor de chave primria e nome de coluna.

Como a principal razo pela qual em seremos os dados em um banco de dados para que possamos recuper-lo os novamente, devemos estar certos de que poderemos recuperar todos dados possveis.

Essa regra afirma que voc deve conhecer apenas trs aspectos para localizar um dado especfico: o nome da tabela, o nome da coluna e a chave primria da linha.

No h nenhuma regra nesse conjunto de doze regras e que afirme categoricamente que cada linha em uma relao de Evans ter uma chave primria nica. Entretanto, uma relao no pode obedecer regra de acesso garantido, a menos que ela tenha uma chave primria nica. Sem uma chave primria nica, voc recuperar algumas linhas com o valor da chave primria utilizado em uma pesquisa, mas no necessariamente a linha exata desejada. Portanto, alguns dados talvez no estejam acessveis sem a capacidade nica de identificar linhas.

Antigos bancos de dados Relacionais no requeriam um qualquer chave primria. possvel criar eu utilizar tabelas sem restries de chave primria. Hoje em dia, entretanto, a SQL permite criar uma tabela sem especificao de uma chave primria, mas a maioria dos SGBD's no permite que voc em si j dados nessa tabela.

Regra 3: tratamento sistemtico de valores nulos

"Valores nulos (distintos da e string de caracteres vazia ou de uma string de caracteres em branco ou de qualquer outro nmero) so suportados completamente em um SGBD relacional para representar de maneira sistemtica as informaes ausentes, independentemente do tipo de dados".

Como voc sabe, nulo um valor de banco de dados especial que significa " desconhecida". A presena dele em um banco de dados traz problemas especiais durante recuperao de dados. Por exemplo, considere o que acontece voc tiver uma relao de funcionrios que contm uma coluna para falar. Assuma que o salrio nulo em algumas


partes das linhas. O que deve acontecer se algum consultar a tabela para todas as pessoas que ganham mais de US$ 60.000? As linhas com nulos devem ser recuperadas ou permanecer fora?

Quando SGBD avaliam nulo em relao ao critrio lgico de valor de um salrio maior que US$ 60.000, ele no pode afirmar se a linha contendo nulo cumprir com os critrios. Talvez compra; talvez no. Por essa razo, dizemos que bancos de dados relacionais utilizam lgica trivalorada. O resultado da avaliao de uma expresso lgica verdadeiro, falso ou talvez.

Primeiro, com SGBD relacional deve armazenaram o mesmo valor de nulo em todas as colunas e linhas onde o usurio no insere explicitamente os valores de dados. O valor utilizado para o nulo deve ser o mesmo, independentemente do tipo de dados da coluna. Observa que o nulo no o mesmo que um caractere de espao em branco; ele tem seu prprio valor ASCII ou UNICODE distinto. Entretanto, na maioria das vezes quando voc v na tela uma tabela de resultados de uma consulta, nulos no aparecem como valores em branco.

Segundo, o SGBD deve ter alguma maneira conhecida e coerente de tratar desses nulos ao realizar consultas. Em geral, voc descobrir que linhas com nulos no so recuperadas por uma consulta como a do exemplo de salrio maior que US$ 60.000, a menos que o usurio solicite explicitamente linhas com um valor de nulo. Atualmente, a maioria dos SGBD's relacionais obedece ao na tabela de verdade lgica trivalorada para determinar o comportamento de recuperao quando eles encontram nulos.

A incluso de nulos em uma relao pode ser extremamente importante. Eles oferecem uma maneira consistente de extinguir entre dados vlidos, como um 0, e dados ausentes. Por exemplo, faz muita diferena saber que o soldo de uma conta a pagar 0 em vez de desconhecido. A conta com comearam nmero zero cancelar algo que gostamos de ver; a conta com saldo desconhecido poder ser um grande problema.

Regra 4: catlogo on-line dinmico baseado no modelo relacional

"A descrio de banco de dados representada no nvel lgico da mesma maneira que dados simples, de modo que usurios autorizados possam aplicar a mesma linguagem relacional que aplicam a dados regulares a sua interrogao".

Uma vantagem da utilizao de estruturas de dados idnticas para um dicionrio de dados, como ocorre com tabelas de dados, que voc tem uma maneira consistente para acessar todos os elementos do banco de dados. Voc precisa aprender apenas uma linguagem de consulta. Isso


tambm simplifica o prprio SGBD, uma vez que ele pode utilizar o mesmo mecanismo para tratar dados sobre o banco de dados (metadados) que ele utiliza para dados sobre a organizao.

Regra 5: a regra da sublinguagem de dados abrangentes

"Um sistema relacional pode suportar vrias linguagens e vrios modos de utilizao de terminal (por exemplo, modo de preenchimento de espaos em branco). Entretanto, h pelo menos uma linguagem cujas instrues podem ser descritos por alguma sintaxe bem definida, como string de caracteres, e que seja abrangente para suportar a todos os seguintes itens:

A definio dos dados Definio da visualizao Manipulao de dados Restries de integridade Limites de transao

Um banco de dados relacional deve ter alguma linguagem que possa manter elementos estruturais do banco de dados, modificar em recuperar dados. Como a maioria dos atuais SGBD as relacionais utilizam SQL como sua principal linguagem de manipulao de dados, parece no haver nenhum problema aqui.

Entretanto, com SGBD que no suporta SQL, mas utiliza uma linguagem grfica, tecnicamente no atenderia essa regra. No obstante, a vrios produtos hoje em dia cuja linguagem grfica pode realizar o todas as tarefas que Codd estou sem uma sintaxe de linha de comando. Teoricamente, esses SGBD as talvez no seja completamente relacionais, mas uma vez que eles possam realizar todas as tarefas relacionais necessrias, voc no perde nada se no tiver a linguagem de linha de comando.

Regra 6: a regra da visualizao de atualizao

"Todas s vezes realizaes que teoricamente so atualizveis so tambm atualizveis pelo sistema".

Essa regra simplesmente significa que se uma visualizao atender aos critrios de atualizao, com SGBD deve ser capaz de tratar dessa atualizao e propagar as atualizaes de volta s tabelas bsicas.


Regra 7: insero de alto nvel, atualizao e excluso

A capacidade de tratar uma relao bsica o uma relao derivada como um nico operando aplicada no apenas a recuperao de dados, mas tambm insero, atualizao e excluso de dados".

Codd quis assegurar que o SGBD pudesse tratar ao mesmo tempo de mltiplas linhas de dados, especialmente quando os dados fossem modificados.

A linguagem SQL fornece essa capacidade para os atuais SGBDs relacionais. O que isso traz para voc? Poder modificar mais de uma linha com um nico comando simplificar lgica da manipulao de dados. Por exemplo, em vez de precisar ler linha por linha de uma relao para localizar as linhas para modificao, voc pode especificar critrios lgicos que identificam as linhas a serem modificadas e deixar que o SGBD encontre as linhas para voc.

Regra 8: independncia de dados fsicos

"Atividades de programas de aplicaes e atividades de terminais permanecem logicamente intactas sempre que alguma alterao ocorrer na representao de armazenamento e o nos mtodos de acesso".

Um dos benefcios da utilizao de um sistema de banco de dados, em vez de um sistema de processamento de arquivos, que o SGBD isola usurio de detalhes de armazenamento fsico.

Isso significa que voc pode mover o banco de dados a partir de um volume de disco para outro, alterar o layout fsico dos arquivos e assim por diante, sem causar nenhum impacto na maneira como os programas de aplicaes e os usurios finais interagem com as tabelas do banco de dados.

A maioria dos SGBDs atuais oferece pouco controle sobre as estruturas de arquivos utilizadas para armazenar dados no disco. Portanto, na prtica, independncia de dados fsicos significa que voc pode mover o banco de dados e a partir de um volume de discos ou diretrio para outro sem afetar as aplicaes ou os usurios interativos. Com algumas excees -em particular, SGBD's deu usurio final baseados no modelo dBase - a maioria dos SGBD's atuais fornecem independncia de dados fsicos.


Regra 9: independncia de dados lgicos

Programas de aplicaes e atividades de terminais permanece logicamente intactos quando so feitas alteraes de qualquer tipo as tabelas bsicas que preservam informaes que teoricamente permitem a estabilidade dos dados".

Independncia de dados lgicos um pouco mais sutil que a independncia de dados fsicos. Em essncia, significa que se voc alterar o esquema, talvez adicionando ou removendo uma tabela ou adicionando uma coluna para uma tabela, as outras partes do esquema que no devem ser afetadas pela alterao permanecem inalteradas.

Como um exemplo, considere o que acontece quando voc adiciona uma tabela a um banco de dados. Uma vez que as relaes so logicamente independentes entre si, adicionar uma tabela no causa absolutamente nenhum impacto sobre qualquer tabela. Para obedecer regra de independncia de dados lgicos, com SGBD deve assegurar que de fato no h nenhum impacto sobre outras tabelas.

Por outro lado, se voc escolher uma tabela do banco de dados, essa modificao no de preservao de informaes. quase certo que os dados sero perdidos quando a tabela for removida. Portanto, no necessrio que aplicaes e usurios interativos no sero afetados pela operao.

Regra 10: independncia de integridade

"Restries de integridade especficas para um banco de dados relacional em particular devem ser definido vez na sublinguagem de dados Relacionais e passveis de serem armazenados no catlogo, no nos programas de aplicaes.

No mnimo duas das seguintes restries de integridade e devem ser suportadas:

1. Integridade de entidade: nenhum componente de uma chave

primria tem permisso para ter um valor nulo 2. Integridade referencial: para cada valor de chave estrangeira no

nulo e distinto em um banco de dados relacional, deve existir um valor de chave primria e que corresponda ao mesmo domnio.


Observe que essa regra requer que a declarao de restries de integridade faa parte de qualquer que seja a linguagem utilizada para definir a estrutura do banco de dados. Alm disso, qualquer tipo de restrio de integridade deve ser armazenado em um dicionrio de dados que possa ser acessado enquanto o banco de dados utilizado.

Quando a IBM lanou seu carro-chefe de banco de dados relacional o DB/2 uma entre duas reclamaes dos usurios foi a falta de suporte para integridade referencial. Quanto a isso, a IBM e outros fornecedores de SGBD omitiram a integridade referencial, pois ela reduzia o desempenho. Todas as vezes que voc modificar uma linha de dados, o SGBD deve ir ao dicionrio de dados, procurar uma regra de integridade e realizar o teste indicado pela regra, tudo isso antes de realizar uma atualizao. Uma verificao de integridade referencial de uma nica coluna pode envolver dois ou mais acessos ao disco, que leva mais tempo do que simplesmente fazer a modificao diretamente na tabela bsica.

Entretanto, sem a integridade referencial os relacionamentos em um banco de dados relacional tornam-se rapidamente inconsistentes. Portanto, consultas de recuperao no necessariamente recuperam todos os dados, pois referncias cruzadas ausentes fazem com que joins omitam dados. Nesse caso, o banco de dados no ser confivel e praticamente inutilizvel. (Tudo bem, a IBM adicionou integridade referencial ao DB/2 bem rapidamente!)

Regra 11: independncia de distribuio

"Um SGBD relacional tem independncia de distribuio.

Um banco de dados distribudo um banco de dados onde os prprios dados so armazenados em mais de um computador. Portanto, o banco de dados a unio de todas as suas partes. Na prtica, as partes no so nicas, mas contm um grande volume de dados duplicados.

Em outras palavras, um banco de dados distribudo deve parecer ao usurio como uma banco de dados centralizado. As aplicaes e os usurios interativos no precisam conhecer o local de armazenamento dos dados, incluindo a localizao de mltiplas cpias dos mesmos dados.

Regra 11: regra da no-subverso

"Se um sistema relacional tiver uma linguagem de baixo nvel (um nico registro de cada vez), essa linguagem de baixo nvel no pode ser utilizada para subverter ou pular as regras de integridade ou restries expressas na linguagem relacional de nvel mais alto (mltiplos registros de cada vez).


Muitos produtos de SGBD na dcada de 1980 tinham linguagens que poderiam acessar diretamente as linhas nas tabelas, separadamente da SQL, que opera em mltiplas linhas de cada vez. Essa regra afirma que no h nenhuma maneira de utilizar essa linguagem de acesso direto para evitar as restries de integridade armazenadas no dicionrio de dados. Todas as regras de integridade devem ser observadas.

Destas doze regras, pelo menos seis devem ser cumpridas para que o SGBD possa ser qualificado como completo relacionalmente.

ASPECTOS BSICOS DE BANCO DE DADOS 43 Integridade

Integridade

Controle de Integridade Semntica do Banco de Dados

O termo integridade utilizado em banco de dados com o seguinte significado: preciso, correo, validade. O grande problema da integridade o de assegurar que os dados no banco de dados se mantenham precisos, corretos, validos. Ou seja, o de preservar o banco de dados contra atualizaes/inseres no vlidas (controle de acesso).

Se o objetivo do controle de acesso ao BD o de evitar que pessoas e/ou programas no autorizados leiam e/ou atualizem a base de dados, ento objetivo dos mecanismos que zelam pela integridade semntica do BD garantir que somente atualizaes permitidas sejam executadas na base de dados.

Por permitidas, entenda-se as modificaes que mantenham a relao entre o mini-mundo (do usurio/da aplicao) e a representao deste no BD.

Requisitos (restries) de Consistncia (Consistency Constraints) dizem respeito consistncia dos dados em sua representao nos nveis mais baixos da arquitetura do SGBD.

Exemplo: no endereo de disco (cilindro, trilha, bloco fsico) deve estar armazenado o bloco de dados lgico (pgina) correto (correspondente).

Em nveis mais altos da arquitetura do SGBD, o nmero de requisitos de consistncia a serem preservados de multiplica.

Exemplo: os endereos de registros apontados por um arquivo de ndice devem sempre refletir o estado atual do arquivo indexado.

Requisitos de Consistncia dos nveis mais baixos da arquitetura do SGBD podem ser derivados durante seu projeto e no dependem de uma aplicao particular (so vlidos para qualquer aplicao).

No nvel mais alto da arquitetura (nvel das estruturas de dados lgicas - modelo externo, dicionrio de dados) devem ser levados em conta e assegurados os relacionamentos entre o mini-mundo no qual o usurio baseia seu trabalho e o mapeamento deste mini-mundo no BD. Este mapeamento especfico e dependente de cada aplicao.


A partir da definio, por parte do usurio, dos estados corretos e das transies de estado corretas no seu mini-mundo, o SGBD deve garantir que o BD reflita somente estes estados e que as operaes sobre o BD reflitam somente estas transies.

A garantia da integridade semntica a garantia de que o estado dos dados do BD est sempre coerente com a realidade para o qual o mesmo foi projetado e criado. No basta ter um esquema com os dados eficientemente bem estruturados, se no existir nenhum controle sobre os valores dos mesmos (falta de confiabilidade). Se no existe gerenciamento de integridade semntica, pode-se ter violaes de domnio (valores no condizentes com a semntica de certo atributo - por exemplo, um empregado com idade de 10 ou 100 anos), dados desconhecidos (ausncia de valor em atributos significativos, como nome do empregado) e relacionamentos incorretos ou inexistentes (por exemplo, a ocorrncia de situaes proibidas, como departamentos sem gerente ou algum sendo gerente de mais de um departamento).

Garantir integridade semntica garantir estados corretos de um dado (verificado sempre aps alguma atualizao no BD) e transies de estado tambm vlidas (s vezes, uma atualizao no BD acarreta outras aes de atualizao sobre outros dados - transparentes para a aplicao - de forma a manter a integridade do esquema).

Um subsistema de integridade semntica de um SGBD controla restries especificadas sobre um esquema. Estas restries (ou regras) so chamadas restries de integridade (RIs). O gerenciamento destas restries envolve trs funes bsicas:

Especificao de RIs: deve ser possvel especificar testes e aes para garantia de integridade. Para tanto, o SGBD deve suportar uma linguagem de especificao de restries (DCL), cujos comandos so compilados e mantidos no catlogo do sistema (DD) para posterior consulta e modificao;

Monitoramento de RIs: sempre que ocorrer uma operao de atualizao sobre um dado, todas as RIs que dizem respeito ao mesmo devem ser consultadas no DD, para verificar se alguma delas no foi violada ou se algo mais (por exemplo, outra atualizao ou a execuo de um procedimento qualquer) deve ser realizado;

Aes para garantia de RIs: quando alguma operao de atualizao gera alguma inconsistncia, devem ser tomadas aes como o impedimento da atualizao (rollback da atualizao) ou a execuo de outros procedimentos para atualizar dados relacionados.

Assim sendo, em toda RI deve ser possvel especificar:

Para quais dados deve-se verificar a regra (alcane da regra);


Quando a regra deve ser verificada (antes, imediatamente aps ou um tempo aps a operao de atualizao);

Que ao deve ser tomada para garanti-la. A existncia de um subsistema de integridade semntica

extremamente vantajosa para as aplicaes que utilizam um SGBD, pois existe total independncia deste controle, ou seja, o gerenciamento de integridade fica a cargo do SGBD. As aplicaes ficam liberadas desta pesada tarefa, sendo que estas apenas submetem operaes ao SGBD e recebem indicao de O.K. ou sinalizaes de violaes e atitudes tomadas para garanti-las.

Classificao dos Requisitos de Integridade (RI)

Os requisitos de integridade podem ser classificados segundo os seguintes aspectos:

Segundo o Seu Alcance (volume de informao associada RI)

a) Atinge um nico atributo de uma relao.

Ex.: e-nome s pode conter letras ou brancos (RI1)

b) Atinge mais de um atributo de uma mesma tupla

Ex: s-total s-oramento (RI2) c) Atinge mais de uma tupla (um registro) do mesmo tipo

(mesma relao)

Ex.: e-no deve ser unvoco (cada tupla em EMP tem valor diferente em e-no) (RI3)

d) Atinge mais de uma tupla que podem ser de tipos diferentes

Ex.: s-totsal (var_seo) = e-sal (i) e-sec (i) = var_seo (RI4)

Segundo o Momento do Teste da Restrio a) Instantnea sempre que o dado associado RI for

inserido ou atualizado, a RI deve ser testada.

Ex.: e-no 0001 e-no 9999 (RI5)


b) Postergada a RI s pode ser testada aps uma srie de operaes sobre o BD (tpico para RIs que atingem mais de uma tupla de relaes diversas).

Ex.: O usurio deseja aumentar o salrio de alguns empregados (da mesma seo). A RI4 s necessita ser testada ao final das atualizaes. (performance!!)

RIs Que Regulamentam a Atualizao de Valores

RIs baseadas em Verses de Valores de Dados. Testes levam em conta a relao (valor_antigo, valor_novo).

Exemplo 1: O salrio do empregado no pode ser rebaixado (RI6) e-sal (novo_valor) e-sal (valor_atual)

Exemplo 2: As transies do estado civil do empregado devem respeitar o seguinte grafo de precedncias:

SOLTEIRO CASADO

VIVO

SEPARADO

DIVORCIADO

RIs Que Devem Ser Testadas na Ocorrncia de Eventos Externos

O momento do teste da RI determinado pela aplicao.

Exemplo: A partir de trs meses de sua data de ingresso na empresa, o salrio do empregado deve refletir o salrio bsico estipulado para sua funo (piso salarial da categoria). (3 meses = perodo de experincia) (RI7) (data_atual - e-dataing 90) e-sal sal_base (e-func)


Mtodos Utilizados no Suporte Especificao de Restries de Integridade

a) Oferecimento de mecanismos embutidos na linguagem de manipulao de dados (DML para a definio das RIs. (A DML pode ser procedural, (ex.: CODASYL) ou descritiva (ex.: SQL, QUEL, QBE)).

b) Especificao de RI associadas ao objeto e integradas especificao do prprio objeto com base no conceito de tipos abstratos de dados (ADT) (proposta nova).

Definio e Teste de Restries de Integridade

Em SGBDs Mais Antigos (No Relacionais)

Restries de Integridade no DBTG (modelo em Rede): As RIs so como procedures em uma linguagem baseada em COBOL. O DBTG oferece uma clusula de sua linguagem de declarao que associa operaes sobre a base de dados com procedures que testam RIs.

ON < command_list> CALL

Esta clusula associada a declaraes de tipos de registros e sets:

C {insert, delete, modify, find,...}

Exemplo: Teste de RI5 durante a insero de um novo empregado:

PROCEDURE P1: IF (e_nr < 0001 OR e_nr > 9999) THEN GO TO TRATA_ERRO_RI5 END P1; DEFINE RECORD_TYPE EMP e_no : CHAR(4); ... ON INSERT CALL P1 END;

Em SGBDs Relacionais

RIs em SQL definio com o uso da DML


Alternativa 1: atravs da clusula ASSERT ASSERT RI5 ON EMP: e-no BETWEEN 0001 AND 9999 IMMEDIATE ASSERT RI2 ON SEO: s-totsal s-oram ASSERT RI4 ON SEO X: s-totsal = (SELECT SUM (e-sal) FROM EMP WHERE s-sec=x.s-no) ASSERT RI6 ON EMP (e-sal): NEW e-sal OLD e-sal

RIs especificadas com ASSERT tem seu teste postergado

bd - aspectos basicos

Documents