Post on 02-Mar-2016
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
Tabela 2 - Tabela ou Relao Empregado
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
Tabela 4 - Tabela ou Relao Empregado
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
Tabela 6 - Tabela ou Relao Empregado
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.
Tabela 10 - 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 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.
Tabela 11 - Tabela ou Relao Funcionrio
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.