Modelo Relacional

7Banco de Dados

Captulo 7 O Modelo Relacional

Vamos conversar sobre o assunto?

No projeto de Banco de Dados, a modelagem lgica ou projeto lgico a terceira

etapa (vide Figura 1), antecedida pela anlise de requisitos e pela modelagem conceitual.

O produto dessa etapa o modelo relacional ou esquema relacional e este justamente o

assunto desse captulo! Esse modelo j dependente do SGBD que for ser escolhido para

a implementao do banco de dados. Logo, atente para o fato de que esse o momento

dessa deciso ser tomada.

Neste captulo, vamos falar sobre o modelo relacional, que um exemplo de

modelo lgico de dados, e sobre os conceitos a ele relacionados.

Figura 1 - Etapas do Projeto de Banco de Dados

O Modelo Relacional (MR)

Vamos relembrar... o que o modelo lgico? um modelo que vai especificar a

representao/declarao dos dados de acordo com o SGBD escolhido, definindo assim a

estrutura de registros do BD (onde cada registro define nmero fixo de campos (atributos)

e cada campo possui tamanho fixo). Um exemplo de modelo lgico o modelo relacional

(MR). Os SGBDs que utilizam o MR so denominados SGBDs Relacionais e, nesta disciplina,

trataremos do projeto lgico apenas desse tipo de SGBD.

8Banco de Dados

O Modelo Relacional foi introduzido por Ted Codd, da IBM Research, em 1970, em

um artigo clssico (Codd, 1970) que imediatamente atraiu a ateno em virtude de sua

simplicidade e base matemtica. O modelo usa o conceito de uma relao matemtica

algo como uma tabela de valores como seu bloco de construo bsica e tem sua base

terica na teoria dos conjuntos.

As primeiras implementaes comerciais do modelo relacional tornaram-se

disponveis no incio da dcada de 80, antes disso, eram utilizados os modelos de redes e

hierrquico (sobre os quais estudamos no Volume 1, captulo 1).

O modelo relacional tem como objetivos: prover esquemas de fcil utilizao;

melhorar a independncia lgica e fsica de dados; prover os usurios com linguagens

de manipulao de BD de alto nvel, permitindo o seu uso por usurios no experientes;

otimizar o acesso aos BDs e melhorar a integridade e segurana dos dados.

O MR representa os dados do BD como relaes1 (tabelas) de nomes nicos. O

conceito de tabelas est intimamente ligado ao conceito de uma relao matemtica de

onde se origina o nome deste modelo. Vamos apresentar, na seo a seguir, cada um dos

conceitos relevantes dentro do contexto do modelo relacional.

Conceitos do Modelo Relacional

Em um ambiente de banco de dados relacional utilizamos alguns conceitos muito

importantes para a correta implantao e operao de qualquer sistema de banco de

dados. Por exemplo, na terminologia do modelo relacional, cada tabela chamada relao

e vai possuir um nome nico que a identifica, cada linha da tabela chamada tupla, cada

cabealho de coluna conhecido como atributo (vide Figura 2).

Figura 2 - Exemplos de Terminologias do Modelo Relacional

Alguns desses novos termos originam-se diretamente da Teoria de Conjuntos, outros

so decorrentes da utilizao de elos lgicos para implementar os relacionamentos entre os

dados armazenados no banco de dados. A seguir, cada um dos conceitos fundamentais do

modelo relacional ser descrito.

Tabela ou Relao

No modelo relacional, a estrutura que armazena os dados referentes a cada uma

das ocorrncias de uma entidade ou relacionamento com atributos do MER chamada de

tabela ou relao.

Uma tabela uma representao bi-dimensional de dados composta de linhas

e colunas. Por exemplo, a tabela de empregados de uma empresa (vide Tabela 1) onde

Comentrio

1 A palavra relao utilizada no sentido de lista ou rol de informaes e no no sentido de associao ou relacionamento.

9Banco de Dados

poderiam ser armazenados dados como o CPF, o nome e o telefone de cada empregado. A

tabela como um todo representaria os empregados da empresa. Cada coluna representaria

um atributo (ex: a primeira coluna da Tabela 1 o CPF ). E cada linha da tabela representa os

dados de um empregado. Por exemplo, a primeira linha da Tabela 1 se refere empregada

de CPF nmero 987675456-98, de nome Ana Marques e cujo telefone 3245-8976.

Tabela 1 - Tabela ou Relao Empregado

CPF Nome Telefone

987675456-98 Ana Marques 3245-8976

765456243-45 Joo Pontes 3124-5645

213415467-89 Marcos Alves 3456-8923

567324980-03 Tnia Gomes 3455-9098

Matematicamente, define-se uma relao como um subconjunto de um produto

cartesiano de uma lista de domnios2. Assim, suponha que D1 denote o domnio do atributo

A1, D2 denote o domnio do atributo A2 e Dn denote o domnio do atributo N da tabela T1.

Qualquer linha da tabela que possui estes atributos denotada pela tupla3 (d1,d2,...,dn) em

que d1, d2 e dn tm como valores possveis (domnios), respectivamente D1, D2 e Dn. Em

geral, uma instncia de T1 um subconjunto de D1 X D2 X ... X Dn.

O conjunto de atributos de uma relao chamado de esquema da relao. O

esquema de uma relao denotado por : R[A1 D1, ..., An Dn] onde:

R o nome da relao;

A1, ..., An a lista de atributos da relao R e

D1, ..., Dn so os domnios de cada um dos atributos da relao R.

Frequentemente, utilizada uma notao simplificada em que omitida a definio

do domnio de cada atributo da relao: R[A1, ..., An]. Por exemplo, o esquema da relao

representada na Tabela 1 seria: Empregado[CPF char4(11), Nome char(50), Telefone

char(9)] ou, na notao simplificada, teramos Empregado[CPF, Nome, Telefone].

Na criao dos esquemas das relaes o nome das relaes ou tabelas devem ser

nicos no banco de dados, devem ser escritos no singular e, de preferncia, devem ser

nomes curtos. Se for usado um nome composto, este deve ser separado por um underline

(_), por exemplo Pessoa_Fisica ou Pessoa_Juridica.

O atributo identificador da relao apresentado sublinhado (esse atributo

identificador dar origem chave primria da relao, como veremos mais a frente). Assim,

se CPF fosse o atributo identificador teramos: Empregado[CPF, Nome, Telefone].

O grau de uma relao o nmero de atributos que a compe. Por exemplo, o grau

da relao Empregado[CPF, Nome, Telefone] trs, porque essa relao possui 3 atributos.

Uma particularidade referente definio de relao que, nesta definio, no

existe qualquer tipo de ordenao ou de definio de ordenao. Assim, por exemplo, as

duas relaes representadas pelas Tabelas 1 e 2 so consideradas idnticas. Afinal, o que

mudou de uma tabela para outra foi apenas a ordem em que os valores de preenchimento

da tabela aparecem.

Comentrio

2 Um domnio contm os valores possveis para um determinado atributo da relao.

Comentrio

3 Uma tupla uma ocorrncia particular de um elemento da tabela. Falaremos sobre esse conceito, em detalheas, mais a frente.

Comentrio

4 O tipo char equivale ao tipo string das linguagens de programao, onde voc pode digitar letras, nmeros e smbolos. Quando voc define um tipo char, voc tem de especificar o tamanho do que preencher o mesmo. Esse tipo pode variar de nome de SGBD para SGBD mas sempre vai ter um correspondente.

10

Banco de Dados


CPF Nome Telefone

213415467-89 Marcos Alves 3456-8923

567324980-03 Tnia Gomes 3455-9098

765456243-45 Joo Pontes 3124-5645

987675456-98 Ana Marques 3245-8976

Linha (Tupla)

Uma ocorrncia em particular de dados em uma tabela ocupa uma linha dessa

tabela. Por exemplo, na Tabela 3, os dados de cada um dos empregados que a compe

ocupam uma linha diferente da tabela. Como existem 4 empregados, a Tabela 3 possui 4

linhas (ou tuplas ou registros). O nmero de linhas ou tuplas de uma relao chamado de

cardinalidade da relao. Logo, a cardinalidade da relao expressa na Tabela 3 quatro.

Cada linha da tabela deve ser nica e deve possuir um atributo identificador. No

caso da Tabela 3, esse identificador o CPF do empregado. O atributo identificador, no

modelo relacional, passa a ser chamado de chave primria (PK) - detalharemos melhor esse

ponto mais a frente.

Tabela 3 - Exemplos de Atributos e Tuplas

Outra definio que pode ser dada para linha ou tupla : um conjunto de pares

(,), em que cada par fornece o valor do mapeamento de um atributo Ai

para um valor Vi, tal que cada valor Vi seja um elemento do domnio Di ou um valor nulo.

Algumas regras para tuplas so: em uma tabela ou relao no devem existir tuplas

ou linhas duplicadas. As linhas de uma tabela no seguem uma ordem especfica. Dessa

forma, as tuplas ou linhas abaixo seriam idnticas:

T = e

T =

Coluna (Atributo)

Cada tipo de informao armazenada em uma tabela uma coluna. Ou seja, cada

11

Banco de Dados

atributo que caracteriza a relao expresso em uma coluna. Toda coluna de uma tabela

deve possuir um nome pelo qual ser referenciada sempre que necessrio. Na verdade,

ao criarmos uma tabela definimos, para cada uma de suas colunas, o seu nome (nome do

atributo) e tambm o seu tipo (numrico, alfabtico, data, etc). Por exemplo, CPF, Nome e

Telefone so atributos (colunas ou campos) da Tabela Empregado, expressos na Tabela 3.

Um nome de atributo deve ser nico em uma tabela e deve expressar o tipo de

informao que ele representa. E o valor de um atributo no deve poder ser decomposto

em mais de uma coluna.

Domnio do Atributo

Domnio de um atributo a faixa de valores que esse atributo pode conter. Em

outras palavras, o conjunto de valores que um determinado atributo pode assumir. Por

exemplo, para o atributo CPF da Tabela 3, o domnio seria o conjunto dos nmeros naturais.

Em outras tabelas quaisquer, por exemplo, o domno do atributo dia do msseria o

conjunto dos nmeros entre 1 e 31. O atributo sexo teria como domnio os mnemnicos

M (para masculino) ou F (para feminino) e assim por diante.

Sempre que identificamos um atributo de uma tabela, temos tambm uma ideia de

qual o tipo de informao que ele poder vir a conter.

Chaves

Uma chave5 um atributo (ou conjunto de atributos) que identifica univocamente

cada entrada de uma relao. Ou seja, por meio de chaves podemos diferenciar as diversas

tuplas pertencentes a uma relao. Como consequncia dessa definio, temos que os

atributos chaves no podem apresentar valores duplicados, nem podem ser nulos.

NULO - No devemos confundir o conceito de nulo com espaos em branco ou o nmero zero, por

exemplo, que so valores conhecidos. Nulo a ausncia de informao.

Uma coluna de preenchimento obrigatrio numa tabela deve possuir todos os seus valores no-

nulos. Se, por exemplo, uma linha da tabela Empregado contiver um nulo na coluna Telefone,

significa que o telefone do empregado correspondente quela linha desconhecido. Assim, ou o

telefone no foi informado por algum motivo ou o empregado no possui telefone, de qualquer

forma, a informao est ausente na tabela.

Uma definio mais formal para chave seria: seja R um esquema de relao. Se

dissermos que um subconjunto K de atributos de R uma superchave6 para R, estaremos

considerando restries para as relaes r(R), nas quais no existem duas tuplas distintas

com mesmos valores em todos os atributos de K. Isto , se as tuplas t1 e t2 fazem parte da

relao r e t1 t2, ento t1[K] t2[K].

Quando h a possibilidade de mais de um atributo (isoladamente) poder ser chave

em uma relao, dizemos que esses atributos so chaves candidatas. Por exemplo, na Tabela

4, CPF e Nome poderiam ser chaves candidatas, porque poderiam ser atributos usados para

localizar uma entrada na tabela.

Comentrio

5 O conceito de chave est diretamente ligado ao de identificador da entidade ou relacionamento que foi estudado no volume anterior, quando foram detalhados os componentes do MER.

Comentrio

6 Superchave o conjunto de um ou mais atributos que nos permitem identificar de maneira unvoca uma tupla de uma relao.

12

Banco de Dados


CPF (PK) Nome Telefone

213415467-89 Marcos Alves 3456-8923

567324980-03 Tnia Gomes 3455-9098

765456243-45 Joo Pontes 3124-5645

987675456-98 Ana Marques 3245-8976

Um dos princpios do modelo relacional diz que uma linha de uma tabela deve

sempre poder ser referenciada de forma nica. Por isso, entre as chaves candidatas, uma

delas deve ser eleita para ser a principal, a chave primria da tabela (Primary Key ou PK),

aquela que realmente identifica univocamente cada tupla da tabela. No caso, para a Tabela

4, a melhor escolha para chave primria seria o atributo CPF, j que essa informao no se

repetiria, de forma alguma, em dois empregados distintos da tabela.

A escolha da chave primria (PK) da tabela influenciada pelas necessidades do domno do mundo

real que est sendo modelado.

Chaves primrias so geralmente indicadas na tabela pela sigla PK (Primary Key) e

podem tambm ser sublinhadas (vide Tabela 4).

As outras chaves candidatas que no forem escolhidas para chave primria, so

chamadas de chaves secundrias. Por exemplo, na Tabela 4, o atributo Nome seria uma

chave secundria.

Muitas vezes, uma tabela no possui, entre seus atributos, um que por si s seja

suficiente para identificar univocamente uma ocorrncia. Nesses casos deve sempre ser

possvel que a combinao de dois ou mais atributos tenha a capacidade de se constituir

numa chave primria. Chamamos a essas chaves primrias formadas pela combinao de

vrios atributos de chaves primrias compostas. Ou seja, uma chave primria composta

uma chave primria que formada por mais de um atributo ou coluna. Geralmente, uma

tabela que represente um relacionamento entre outras duas tabelas (originada de um

relacionamento do MER) ir possuir chaves primrias compostas. Por exemplo, a tabela

Alocao (vide Tabela 5), ter como chaves primrias os atributos CPF e Cod_Projeto. Isso,

porque para descobrir qual a funo de um empregado em um projeto, precisamos dessas

duas informaes. Nenhum dos atributos isoladamente poderia fornecer essa informao.

Tabela 5 - Tabela ou Relao Alocao

CPF (PK) Cod_projeto (PK) Funo

213415467-89 002 Analista

567324980-03 001 Consultor

765456243-45 003 Suporte

987675456-98 002 Programador

13

Banco de Dados


CPF (PK) Nome Telefone

213415467-89 Marcos Alves 3456-8923

567324980-03 Tnia Gomes 3455-9098

765456243-45 Joo Pontes 3124-5645

987675456-98 Ana Marques 3245-8976

Tabela 7 - Tabela ou Relao Projeto

Cod_projeto (PK) Nome Projeto

001 SOFTHOUSE

002 GEOPROC

003 LINUX WORLD

Uma tabela pode incluir entre seus atributos a chave primria de outra tabela.

Essa chave chamada chave estrangeira. Ou seja, uma chave estrangeira uma coluna

(ou combinao de colunas) que indica um valor que deve existir como chave primria em

uma outra tabela (chamada de Tabela Pai). Por exemplo, na tabela Alocao (vide Tabela

5), as colunas CPF e Cod_Projeto so chaves estrangeiras, porque elas so chave primria,

respectivamente, das tabelas Empregado (vide Tabela 6) e Projeto (vide Tabela 7).

Vamos definir novamente com outras palavras: uma chave estrangeira de uma

relao R1 um atributo (ou conjunto de atributos) que referencia a chave primria de uma

outra relao R2. Dessa forma, para qualquer tupla de R1, o valor da chave estrangeira deve

ser igual ao valor da chave primria de alguma tupla da relao R2 referenciada, ou deve ser

o valor nulo (se a chave estrangeira no fizer parte da chave primria da relao R1). Com

isso queremos dizer que o atributo que chave estrangeira em uma relao R1, pode ou no

fazer parte da chave primria de R1. No exemplo de chave estrangeira dado anteriormente,

as chaves estrangeiras CPF e Cod_Projeto fazem parte da chave primria da tabela Alocao

(vide Tabela 5). Porm, a chave estrangeira pode no fazer parte da chave primria. Observe

a tabela Funcionrio (vide Tabela 8). Ela possui um campo Cod_Depto que chave primria

da tabela Departamento (vide Tabela 9). Logo, na tabela Funcionrio, o atributo Cod_Depto

uma chave estrangeira. Chaves estrangeiras so indicadas pela sigla FK (Foreign Key).

Tabela 8 - Tabela ou Relao Funcionrio

CPF (PK) Nome Cod_Depto (FK)

213415467-89 Marcos Alves 11

567324980-03 Tnia Gomes 22

765456243-45 Joo Pontes 11

987675456-98 Ana Marques 22

14

Banco de Dados

Tabela 9 - Tabela ou Relao Departamento

Cod_Depto (PK) Nome

11 Vendas

22 Financeiro

Uma chave estrangeira formada por mais de uma coluna chamada de chave

estrangeira composta.

No modelo relacional os relacionamentos representados no MER passam a ser

representados atravs de chaves estrangeiras. Ou seja, as chaves estrangeiras tornam

possvel a associao lgica entre tabelas distintas. Isso ficar mais claro no prximo captulo

quando forem apresentadas as regras de derivao do MR a partir do MER.

Regras de Integridade Fundamentais

O modelo relacional, ao definir conceitos como Tabela, Tupla, Atributo, Nulo,

Domnio, Chave Primria e Chave Estrangeira deixa implcitas algumas regras fundamentais

para a manuteno da consistncia do banco de dados. Elas so chamadas de Regras de

Integridade e tratam dos cuidados que analistas, projetistas e programadores devem

observar ao implementar as rotinas de Incluso, Alterao e Excluso de dados nas bases

de dados. Na prtica, as restries de integridade fornecem meios para assegurar que

mudanas feitas no banco de dados no resultem na perda da consistncia sobre estes

dados.

Vamos ver agora dois dos principais tipos de integridade a serem mantidas em

um banco de dados adequadamente projetado: a Integridade de Entidade e a Integridade

Referencial. Posteriormente, discutiremos regras de integridade complementares e regras

de integridade semntica.

Integridade de Entidade (ou de Identidade ou Existencial)

Refere-se s chaves primrias e procura garantir que toda e qualquer linha de uma

tabela deve poder ser acessada com base apenas no contedo de sua chave primria. Para

isso, algumas regras devem ser observadas:

Toda tupla tem um conjunto de atributos que a identifica de maneira nica na

relao (Integridade de Chave).

Nenhum atributo que faa parte de uma chave primria pode ter valor nulo (eles

devem ser NN = not null).

No se deve permitir que em uma mesma tabela existam duas ocorrncias (tuplas)

com chaves primrias iguais. Ou seja, os atributos que so chave primria devem

ser nicos (ND = No Duplicate ou Unique).

Isso significa que os contedos de todos os atributos que constituem uma chave

primria devem ser conhecidos e nicos. Um contedo nulo representa uma informao

desconhecida ou, em outras palavras, a ausncia da informao, o que no pode ser

permitido em qualquer elemento de uma chave primria.

Algumas recomendaes para se alcanar a integridade de entidade so:

15

Banco de Dados

Selecione chaves primrias que realmente tenham preenchimento nico no

domnio do problema.

Se possvel, prefira chaves primrias simples e numricas.

Se no houver nenhuma coluna que possa ser uma chave candidata, utilize chaves

primrias sequenciais, geralmente, atribudas pelo sistema.

Integridade Referencial

Diz respeito s chaves estrangeiras e visa manter a integridade dos relacionamentos

previstos no banco de dados. Ou seja, a integridade referencial cuida para que uma

relao possa ter um conjunto de atributos que contm valores com mesmo domnio de

um conjunto de atributos que forma a chave primria de outra relao. Este conjunto

chamado chave estrangeira.

Na definio dos cuidados referentes a esse tipo de integridade, utilizaremos dois

conceitos:

Tabela-Pai (Parent Table): aquela onde o atributo de relacionamento desempenha

o papel de chave primria.

Tabela-Filho (Dependent Table): tabela onde o atributo de relacionamento

desempenha o papel de chave estrangeira.

Para manter a integridade referencial, a regra bsica : o contedo de uma chave

estrangeira deve, necessariamente, ser igual ao de uma ocorrncia da Tabela-Pai ou ento

ser nulo. Vale ressaltar que o valor da chave estrangeira s poder ser nulo na Tabela-Filho,

se o atributo que for chave estrangeira no fizer parte da chave primria da Tabela-Filho.

Por exemplo, na ltima tupla da tabela Funcionrio (vide Tabela 10), temos que o

Cod_Depto NULL. Isso possvel apenas porque o atributo Cod_Depto no faz parte da

chave primria da tabela Funcionrio. E deve significar que, por enquanto, a funcionria

Ana Marques no foi alocada em nenhum departamento (vamos supor que ela acabou

de ser contratada). J todas as outras tuplas da tabela Funcionrio possuem o Cod_Depto

preenchido e, para que a integridade referencial seja mantida, como esse atributo chave

estrangeira, ele deve existir como chave primria em alguma outra tabela. No caso, na

tabela Departamento (vide Tabela 9). Nesse exemplo fornecido, a tabela Funcionrio a

Tabela-Filho e a tabela Departamento a Tabela-Pai.


CPF (PK) Nome Cod_Depto (FK)

213415467-89 Marcos Alves 11

567324980-03 Tnia Gomes 22

765456243-45 Joo Pontes 11

987675456-98 Ana Marques NULL

16

Banco de Dados

Observao

Uma chave estrangeira pode referenciar-se a um atributo da sua prpria tabela (caso que ocorrer com os auto-relacionamentos do MER). Por exemplo, a tabela Funcionrio (vide Tabela 11) poderia ter, para cada funcionrio, quem o seu supervisor direto. Assim, o campo CPF_Supervisor, que considerado chave estrangeira, a chave primria da prpria tabela Funcionrio e no de outra tabela qualquer.


CPF (PK) Nome CPF_Supervisor (FK)

213415467-89 Marcos Alves 765456243-45

567324980-03 Tnia Gomes 765456243-45

765456243-45 Joo Pontes NULL

As consequncias da Integridade Referencial refletem-se nas consistncias

necessrias ao se proceder s operaes de Incluso, Alterao e Excluso de dados nas

Tabelas Pai e Filho. Veja as regras no Quadro 1.

17

Banco de Dados

Quadro 1 - Regras de Incluso, Alterao e Excluso para manter a Integridade Referencial

Operao Tabela_Pai Tabela-Filho

InclusoA incluso de dados na tabela-pai no tem

nenhuma implicao ou problema.

A incluso de dados na Tabela-

Filho deve atentar para o fato de

que no ser possvel incluir uma

nova tupla se o valor do campo

que for chave estrangeira j no

estiver cadastrado na Tabela-Pai.

Alterao

Se a alterao envolver o valor da chave

primria, deve-se utilizar um dos seguintes

critrios:

A chave no deve ser alterada se estiver

sendo utilizada em alguma tabela-filho.

A chave deve ser alterada e deve-se colocar

NULL nas chaves estrangeiras presentes na(s)

Tabela(s)-Filho (contanto que o valor em

questo no faa parte da chave primria da(s)

Tabela(s)-Filho correspondente(s)).

A chave deve ser alterada e o novo valor deve

ser colocado no campo que chave estrangeira

em todas as tabelas-filho relacionadas.

Se a alterao envolver o

atributo que chave estrangeira,

a alterao s deve ser realizada

usando valores que existam na

tabela pai (podendo tambm

usar o valor NULL, se essa chave

estrangeira no fizer parte da

chave primria da Tabela-Filho).

Excluso

Para excluir uma tupla dessa tabela, deve-se

utilizar um dos seguintes critrios:

No deletar, se a tupla estiver sendo utilizada

em uma Tabela-Filho.

Deletar a tupla e colocar NULL nas chaves

estrangeiras das Tabelas-Filhos afetadas (isso se

o atributo envolvido no fizer parte da chave-

primria da Tabela-Filho).

Deletar e, tambm, eliminar todas as tuplas

das Tabelas-Filho que faam uso do valor da

tupla sendo eliminada.

A excluso de Dados na Tabela-

Filho no tem nenhuma

implicao ou problema.

As restries de integridade devem ser implementadas pelo SGBD. Muitos SGBDs implementam

integridade de entidade, mas no implementam integridade referencial.

Regras de Integridade Complementares

Alm das regras de integridade de entidade e referencial, um banco de dados

relacional pode suportar um conjunto adicional de regras (ou restries) cuja finalidade

18

Banco de Dados

especificar aspectos prprios de cada coluna e respectivo domnio, complementando

com isso a definio de suas caractersticas lgicas. As principais restries de integridade

complementares tratam da obrigatoriedade e unicidade de valores e sobre conjuntos de

valores permitidos. Vamos s regras:

Obrigatoriedade - Indica se deve ou no ser permitida a existncia de nulos em uma

coluna (ou seja, se um atributo pode ou no ser nulo). Colunas que no aceitam

nulos so de preenchimento obrigatrio como, por exemplo, o nome de um

funcionrio na tabela de funcionrios. Campos que no possuam obrigatoriedade

de preenchimento so considerados campos opcionais. Por exemplo, o nmero do

telefone poderia ser um campo opcional, dependendo do domnio, visto que ainda

podem haver pessoas que no possuem nmero de telefone. A definio de se um

campo ser de preenchimento obrigatrio ou no, vai depender muito do domnio

do mundo real sendo modelado.

Unicidade - Indica se deve ser permitido ou no que uma coluna possua valores

idnticos em duas ou mais linhas. Uma coluna que no pode possuir valores

repetidos uma coluna de valores nicos.

Verificao de Valores Especficos - Indica explicitamente qual o conjunto de

valores permitidos para uma determinada coluna. Por exemplo, para a coluna Sexo

de uma tabela Empregado s poderiam ser aceitos os valores M ou F. Qualquer

outro valor deveria ser recusado.

Restries de Integridade Semntica

So restries especificadas e mantidas num banco de dados relacional pelo

programa de aplicao e que so inerentes a aplicao sendo desenvolvida. Ou seja, so

as regras de negcio do domnio do mundo real sendo implementado. Por exemplo, em

um determinado sistema pode-se querer implementar a restrio que o salrio de um

empregado no pode ser maior do que o salrio do seu supervisor direto ou que o

nmero mximo de horas por semana que um empregado pode trabalhar em projetos de

40 horas (suponha que a empresa no permite horas extras) ou, ainda, a data de entrega

de um pedido no pode ser inferior data em que o pedido foi realizado. Tais restries,

como dito, so especficas do domnio sendo implementado e necessitam ser programadas

em cada aplicao que v fazer uso do banco de dados.

As 12 Regras de Codd

Edgard F. Codd, em 1985, estabeleceu as 12 regras de Codd que determinam o

quanto um banco de dados relacional. Algumas vezes as regras se tornam uma barreira

e nem todos os SGBDs relacionais fornecem suporte a elas. De qualquer forma, a ttulo de

conhecimento, vamos apresent-las a seguir. Lembramos que nem todas as regras sero

completamente compreendidas nesse momento, mas o sero at o final da disciplina.

Regra 1 - Regra das informaes em tabelas: As informaes a serem armazenadas

no banco de dados devem ser apresentadas como relaes (tabelas formadas por linhas e

colunas) e o vnculo de dados entre as tabelas deve ser estabelecido por meio de valores de

campos comuns (chaves estrangeiras).

Regra 2 - Regra de acesso garantido: Todo e qualquer valor atmico em um BD

relacional possui a garantia de ser logicamente acessado pela combinao do nome da

tabela, do valor da chave primria e do nome do campo/coluna que deseja acessar. Isso

19

Banco de Dados

porque, com o nome da tabela, se localiza a tabela desejada. Com o valor da chave primria

a tupla desejada dentro da tabela localizada. E com o nome do campo/coluna se acessa a

parte desejada da tupla.

Regra 3 - Regra de tratamento sistemtico de valores nulos: Valores nulos devem

ser suportados de forma sistemtica e independente do tipo de dado para representar

informaes inexistentes e informaes inaplicveis. Deve-se sempre lembrar que valores

nulos devem ter um tratamento diferente de valores em branco.

Regra 4 - Regra do catlogo relacional ativo: Toda a estrutura do banco de dados

(domnios, campos, tabelas, regras de integridade, ndices, etc) deve estar disponvel em

tabelas (tambm referenciadas como catlogo). Sua manipulao possvel por meio de

linguagens especficas (por exemplo, SQL). Essas tabelas so, geralmente, manipuladas pelo

prprio sistema no momento em que o usurio efetua alteraes na estrutura do banco de

dados (por exemplo, a incluso de um novo atributo em uma tabela).

Regra 5 - Regras de atualizao de alto-nvel: Essa regra diz que o usurio deve

ter capacidade de manipular as informaes do banco de dados em grupos de registros, ou

seja, ser capaz de inserir, alterar e excluir vrios registros ao mesmo tempo7.

Regra 6 - Regra de sub-linguagem de dados abrangente: Pelo menos uma

linguagem, com sintaxe bem definida, deve ser suportada, para que o usurio possa

manipular a estrutura do banco de dados (como criao e alterao de tabelas), assim

como extrair, inserir, atualizar ou excluir dados, definir restries de integridade e de acesso

e controle de transaes (commit e rollback8, por exemplo). Deve ser possvel ainda a

manipulao dos dados por meio de programas aplicativos.

Regra 7 - Regra de independncia fsica: Quando for necessria alguma

modificao na forma como os dados esto armazenados fisicamente, nenhuma alterao

deve ser necessria nas aplicaes que fazem uso do banco de dados (isolamento), assim

como devem permanecer inalterados os mecanismos de consulta e manipulao de dados

utilizados pelos usurios finais.

Regra 8 - Regra de independncia lgica: Qualquer alterao efetuada na estrutura

do banco de dados como incluso ou excluso de campos de uma tabela ou alterao no

relacionamento entre tabelas no deve afetar o aplicativo utilizado ou ter um baixo impacto

sobre o mesmo. Da mesma forma, o aplicativo somente deve manipular vises9 dessas

tabelas.

Regra 9 - Regra de atualizao de vises: Uma vez que as vises dos dados de uma

ou mais tabelas so, teoricamente, suscetveis a atualizaes, ento um aplicativo que faz

uso desses dados deve ser capaz de efetuar alteraes, excluses e incluses neles. Essas

atualizaes, no entanto, devem ser repassadas automaticamente s tabelas originais. Ou

seja, a atualizao em uma viso deve refletir na atualizao das tabelas representadas por

essa viso.

Regra 10 - Regra de independncia de integridade: As vrias formas de integridade

de banco de dados (integridade de entidade, integridade referencial e restries de

integridade complementares) precisam ser estabelecidas dentro do catlogo do sistema ou

dicionrio de dados e serem totalmente independentes da lgica dos aplicativos. Assim, os

aplicativos no devem ser afetados quando ocorrerem mudanas nas regras de restries

de integridade.

Regra 11 - Regra de independncia de distribuio: Alguns SGBDs, notadamente os

que seguem o padro SQL, podem ser distribudos em diversas plataformas/equipamentos

que se encontrem interligados em rede. Essa capacidade de distribuio no pode afetar a

funcionalidade do sistema e dos aplicativos que fazem uso do banco de dados. Em resumo,

Comentrio

7 Veremos como fazer isso no ltimo volume desta disicplina, quando estivermos estudando a linguagem SQL.

Comentrio

8 Commit serve para confirmar as operaes realizadas no banco de dados. Rollback serve para desfazer uma operao que ainda no tenha sido confirmada.

Comentrio

9 Viso: uma relao virtual que no faz parte do esquema conceitual do BD, mas que visvel a um grupo de usurios. Em outras palavras, uma viso uma tabela virtual que definida a partir de outras tabelas, contendo sempre os dados atualizados.

20

Banco de Dados

as aplicaes no so logicamente afetadas quando ocorrem mudanas geogrficas dos

dados (caso dos BDs distribudos).

Regra 12 - Regra no-subversiva: O sistema deve ser capaz de impedir qualquer

usurio ou programador de transgredir os mecanismos de segurana, regras de integridade

do banco de dados e restries, utilizando algum recurso de linguagem de baixo nvel que

eventualmente possam ser oferecidos pelo prprio sistema.

Conhea Mais

Neste captulo foram vistos conceitos bsicos do modelo relacional. Para obter mais

informaes ou materiais diversificados para o que foi visto aqui, voc pode proceder a

uma pesquisa usando o Google (www.google.com.br) com as palavras chaves Modelagem

Lgica + Banco de Dados ou Modelo Relacional ou ainda Esquema Relacional. Voc

vai ver que vir muito material. Entre eles: apostilas, notas de aula, reportagens, etc.

Adicionalmente, voc pode consultar qualquer livro sobre banco de dados,

pois qualquer um deles ter um ou mais captulos voltados para a explicao do modelo

relacional. Entre os livros que podemos indicar esto:

HEUSER, CARLOS ALBERTO. Projeto De Banco De Dados Srie Livros Didticos,

V.4. Bookman Companhia Ed., 6 Edio - 2009

SILBERSCHATZ, Abraham; KORTH, Henry F; SUDARSHAN, S. Sistema de banco de

dados. Traduzido por Daniel Vieira. Rio de Janeiro: Elsevier;Campus, 2006.

ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4a. ed. So

Paulo: Pearson Education do Brasil, 2005.

DATE, C. J. Introduo a sistemas de bancos de dados. Rio de Janeiro: Campus,

2000.

ALVES, W.P. Fundamentos de Bancos de Dados. Editora rica, 2004.

Voc Sabia?

A linguagem padro dos Bancos de Dados Relacionais a Structured Query Language, ou simplesmente SQL, como mais conhecida. Ela ser assunto do prximo volume (Volume 4) da disciplina.

Aprenda Praticando

Vamos dar uma olhada novamente em questes de concurso?

NCE-UFRJ - 2001 - TRE-RJ - Analista Judicirio - Especialidade - Anlise de Sistemas

- Desenvolvimento

1) Sobre os conceitos de domnio, atributo e relacionamento, correto afirmar que:

a) um domnio definido pelo conjunto dos atributos pertencentes a um

relacionamento;

21

Banco de Dados

b) domnio e atributo representam um nico conceito semntico;

c) um atributo considerado identificador se pertencer ao domnio que define

um relacionamento;

d) todos os atributos de uma relao devem pertencer a um mesmo domnio;

e) domnio so os valores possveis que um atributo pode assumir.

2) A cardinalidade de uma relao caracterizada por:

a) Nmero de atributos dessa relao;

b) Nmero de campos dessa relao;

c) Quantidade de chaves estrangeiras da relao;

d) Nmero de tuplas de uma relao;

e) Nenhuma das respostas anteriores.

3) Uma chave estrangeira:

a) Pode conter valores que no existem na Tabela-Pai (tabela referenciada);

b) Pode no pertencer chave primria;

c) Tem de pertencer, obrigatoriamente, chave primria;

d) Podem sempre assumir o valor nulo;

e) Nenhuma das respostas anteriores.

Fundao Getlio Vargas 2008

4) No contexto de Banco de Dados, um conceito assegura que um valor que aparece

em uma tabela para um determinado conjunto de atributos aparea em outro

conjunto de atributos de outra tabela. Por exemplo, se cristalina o nome de uma

agncia que aparece em uma tupla da tabela conta, ento deve existir uma tupla

cristalina na tabela agencia. Esse conceito definido como um sistema de regras,

utilizado para garantir que os relacionamentos entre tuplas de tabelas relacionadas

sejam vlidas e que no exclui ou altera, acidentalmente, dados relacionados. Trata-

se do seguinte conceito:

a) Integridade Funcional;

b) Dependncia Funcional;

c) Integridade Relacional;

d) Dependncia Referencial;

e) Integridade Referencial.

(Tcnico de Tecnologia da Informao/UFT/FCC/2005)

5) Os dois principais tipos de integridade a serem mantidos em um banco de dados

relacional adequadamente projetado so:

a) Integridade Existencial e Integridade Permanente;

b) Integridade de Entidade e Integridade de Relacionamento;

c) Integridade de Entidade e Integridade Referencial;

d) Integridade Permanente e Integridade Referencial;

e) Integridade Existencial e Integridade de Entidade.

(Administrador/PM SANTOS/FCC/2005)

22

Banco de Dados

6) Um tipo de dado especfico, como por exemplo Nome do Funcionrio, armazenado

numa localizao da estrutura do banco de dados denominada.

a) Tabela;

b) Linha;

c) Planilha;

d) Coluna;

e) Registro.

Respostas:

1) E O domnio de um atributo so os valores que ele pode assumir. Ou seja, o tipo

deste atributo. Por exemplo, o atributo dia do ms tem como domnio os valores

naturais entre 1 e 31.

2) C A cardinalidade de uma relao o nmero de linhas ou tuplas dessa relao.

Assim, uma relao com quatro tuplas, tem cardinalidade 4.

3) B Uma chave estrangeira pode no pertencer chave primria, no pode conter

valores que no existam na tabela-pai e s podem assumir valor nulo se no

pertencer chave primria da tabela onde chave estrangeira.

4) E Integridade Referencial. Ela checa todas as validaes necessrias referentes ao

uso de chaves estrangeiras.

5) C os dois principais tipos de integridade que podem ser verificados em um BD

relacional so a integridade de entidade (que se referem s checagens da chave

primria) e a integriadade referencial (que se refere s checagens da chave

estrangeira).

6) D Nome do funcionrio tipicamente um atributo e um atributo representado

no BD relacional por uma coluna.

Atividades e Orientaes de Estudo

Agora vamos exercitar o que foi estudado neste captulo. Assim sendo, faa as

atividades sugeridas a seguir. Lembre que exercitar vai ajud-lo(a) a fixar melhor o contedo

estudado. E o contedo desse captulo fundamental para o captulo seguinte, onde vamos

aprender a construir o Modelo Relacional. Mos obra!

Atividades Prticas:

Responda as questes a seguir em um documento de texto (doc) e poste as respostas

no ambiente virtual, no local indicado. Esse trabalho deve ser feito individualmente.

(Exerccios adaptados do livro de Carlos Heuser (1998) - captulo 4).

Exerccio 1: Abaixo aparecem diversos esquemas de relao que compem um

banco de dados relacional. Identifique nestes esquemas, da maneira apropriada, as

chaves primrias e chaves estrangeiras:

Aluno (CodigoAluno,Nome,CodigoCurso)

Curso(CodigoCurso,Nome)

23

Banco de Dados

Disciplina(CodigoDisciplina,Nome,Creditos,CodigoDepartamento)

Curriculo(CodigoCurso,CodigoDisciplina,Obrigatria-Opcional)

Conceito(CodigoAluno,CodigoDisciplina,Ano-Semestre,Conceito)

Departamento(CodigoDepartamento,Nome)

Exerccio 2: Considere o esquema das relaes de um BD relacional a seguir:

Paciente(CodigoConvenio (FK), NumeroPaciente, Nome)

Convenio(CodigoConvenio, Nome)

Medico(CRM, Nome, Especializao)

Consulta(CodigoConvenio (FK), NumeroPaciente (FK), CRM(FK), Data-Hora)

A partir desse esquema, explique que verificaes/checagens deveriam ser feitas

pelo SGBD para garantir integridade referencial nas seguintes situaes:

a) Uma linha includa na tabela Consulta.

b) Uma linha excluda da tabela Paciente.

Vamos Revisar?

Voc estudou, neste captulo, os conceitos bsicos referentes ao modelo relacional.

Entre eles, os conceitos de tabela ou relao, tuplas ou linhas, atributos ou colunas e chaves

(chave candidata, primria, secundria e estrangeira). Esses conceitos sero todos utilizados

no prximo captulo onde voc aprender a derivar o modelo relacional a partir do modelo

entidade-relacionamento. Adicionalmente, foram vistos tambm neste captulo os principais

tipos de integridade (de entidade e referencial), alm de integridades complementares e

integridade semntica.

24

Banco de Dados

Captulo 8

O que vamos estudar neste captulo?

Neste captulo, vamos estudar os seguintes temas:

Como derivar o MR a partir do MER.

Metas

Aps o estudo deste captulo, esperamos que voc consiga:

Derivar o MR a partir do MER.

Verificar a corretude do modelo derivado.

Modelo Relacional

Documents

Transcript of Modelo Relacional