Banco 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.

Banco 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.

Comentrio
1

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

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

Banco 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 987675456-98 765456243-45 213415467-89 567324980-03 Nome Ana Marques Joo Pontes Marcos Alves Tnia Gomes Telefone 3245-8976 3124-5645 3456-8923 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
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.
4

Banco de Dados

Tabela 2 - Tabela ou Relao Empregado CPF 213415467-89 567324980-03 765456243-45 987675456-98 Nome Marcos Alves Tnia Gomes Joo Pontes Ana Marques Telefone 3456-8923 3455-9098 3124-5645 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 (<atributo>,<valor>), 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 = <(CPF, 987675456-98), (Nome, Ana Marques), (Telefone, 3245-8976)> e T = <(Telefone, 3245-8976), (CPF, 987675456-98), (Nome, Ana Marques)>

Coluna (Atributo)
Cada tipo de informao armazenada em uma tabela uma coluna. Ou seja, cada

10

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 nonulos. 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.
5

Comentrio
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

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.

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

11

Banco de Dados

Tabela 4 - Tabela ou Relao Empregado CPF (PK) 213415467-89 567324980-03 765456243-45 987675456-98 Nome Marcos Alves Tnia Gomes Joo Pontes Ana Marques Telefone 3456-8923 3455-9098 3124-5645 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) 213415467-89 567324980-03 765456243-45 987675456-98 Cod_projeto (PK) 002 001 003 002 Funo Analista Consultor Suporte Programador

12

Banco de Dados

Tabela 6 - Tabela ou Relao Empregado CPF (PK) 213415467-89 567324980-03 765456243-45 987675456-98 Nome Marcos Alves Tnia Gomes Joo Pontes Ana Marques Telefone 3456-8923 3455-9098 3124-5645 3245-8976

Tabela 7 - Tabela ou Relao Projeto Cod_projeto (PK) 001 002 003 Nome Projeto SOFTHOUSE GEOPROC 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) 213415467-89 567324980-03 765456243-45 987675456-98 Nome Marcos Alves Tnia Gomes Joo Pontes Ana Marques Cod_Depto (FK) 11 22 11 22

13

Banco de Dados

Tabela 9 - Tabela ou Relao Departamento Cod_Depto (PK) 11 22 Nome

Vendas 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:

14

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) 213415467-89 567324980-03 765456243-45 987675456-98 Nome Marcos Alves Tnia Gomes Joo Pontes Ana Marques Cod_Depto (FK) 11 22 11 NULL

15

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) 213415467-89 567324980-03 765456243-45 Nome Marcos Alves Tnia Gomes Joo Pontes CPF_Supervisor (FK) 765456243-45 765456243-45 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.

16

Banco de Dados

Quadro 1 - Regras de Incluso, Alterao e Excluso para manter a Integridade Referencial Operao Tabela_Pai Tabela-Filho A incluso de dados na TabelaFilho deve atentar para o fato de Incluso A incluso de dados na tabela-pai no tem nenhuma implicao ou problema. que no ser possvel incluir uma nova tupla se o valor do campo que for chave estrangeira j no estiver cadastrado na Tabela-Pai. 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. 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 chaveprimria 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 TabelaFilho no tem nenhuma implicao ou problema. Se a alterao envolver o atributo que chave estrangeira, a alterao s deve ser realizada Alterao 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

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

17

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

18

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,
8

Comentrio
7

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

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

Comentrio
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.
9

19

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., 6Edio - 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;

20

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. Tratase 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)

21

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)

22

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.

23

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.

24