O MODELO RELACIONAL ‘* Como 0s dados sao representados no modelo relacional? * Quais restrigdes de integridade podem ser expressas? ** Como os dados podem ser criados e modificados? ‘* Como os dados podem ser manipulados e consultados? ‘7 Como podemos eriar, modificar e consultar tabelas usando SQL? ‘+ Como obtemos um projeto de banco de dados relacional com base em um diagra- ma ER? © O que sao visdes e por que elas so usadas? ™ Conceltos-chave: relacao, esquema, instancia, tupla, campo, dominio, gran, cardi- nalidade; DDL SQL, CREATE TABLE, INSERT, DELETE, UPDATE; estricoes de integridade, restrigdes de dominio, restricdes de chave, PRIMARY KEY, UNIQUE, restrigoes de chave estrangoira, FOREIGN KEY; manutencSo da integridade refe- encial, restrigdes adiadas e imediatas; consultas relacionais; projeto logico de ban- ER usando SQL; visdes, visdes ¢ independéncia légica, Seguranga; criando visoes em SQL, atualizando visdes, consultando visoes, eliminando visées. TABELA: uma organizagéo de palavras, niimeros ou sinais, ou uma combinagtio de- les, como em colunas paralelas, para exibir um conjunto de fatos ou relagdes em uma forma definitiva, compacta e abrangente; uma sinopse ou esquema. ~ Webster's Dictionary of the English Language (0 modelo hierarquico eo modelo de rede); 0 modelo relacional revolucionou a area dle banco de dados e suplantou em muito esses modelos iniciais. Foren desenvolvidos Prototipos de sistemas de gerenciamento de banco de dados relacional em Projetos de Pesquisa pioneiros na IBM e na UC-Berkeley, em meados dos anos 1970, ©, logo depois disso, varios fabricantes estavam oferecendo produtos de banco de dados relacional. 48O Modelo Relacional 49 Atualmente, o modelo relacional é de longe o modelo de dados dominante e é a base dos SGBDs lideres do mercado, incluindo a famflia DB2 da IBM, o Informix, o Oracle, o Sybase, o Access e o SQLServer, da Microsoft, o FoxBase e o Paradox. Os sistemas de banco de dados relacional sao onipresentes no mercado e representam um negécio de bilhdes de délares. SQL: Originalmente desenvolvida como linguagem de consulta do SGBD rela- cional pioneiro da IBM, o System-R, a linguagem de consulta estruturada (SQL, de Structured Query Language) tornou-se a mais usada para criar, manipular e consultar SGBDs relacionais. Como muitos fabricantes oferecem produtos SQL, ha necessidade de um padrao que defina a ‘SQL oficial’. A existéncia de um pa- drao permite aos usudrios medir a inteireza da versio de SQL de determinado fabricante. O padrao também permite aos usudrios distinguir recursos da SQL especificos de um produto daqueles que sao padronizados; um aplicativo que conta com recursos nao padronizados 6 menos portavel. O primeiro padrio SQL foi desenvolvido em 1986 pelo American National Standards Institute (ANSI) e foi chamado SQL-86. Houve uma pequena revisio em 1989, chamada $QL-89, ¢ uma revistio maior, em 1992, chamada SQL-92. A International Standards Organization (ISO) colaborou com o ANSI no desen- volvimento do padraéo SQL-92. Atualmente, a maioria dos SGBDs comerciais suporta a versdo SQL:1999 do padrao, uma extensao importante da SQL-92 ado- tada recentemente. Nossa abordagem da SQL é baseada no padréo SQL:1999, mas também € aplicdvel ao padrao SQL-92; os recursos exclusivos do padrao $QL:1999 séio mencionados explicitamente. O modelo relacional é muito simples e elegante: um banco de dados é uma colegio de uma ou mais relagées, em que cada relagdo 6 uma tabela com linhas e colunas. Essa representagéo tabular simples permite que até usuarios iniciantes entendam o contetido de um banco de dados e possibilita o uso de linguagens de alto nfvel simples para consultar os dados. As principais vantagens do modelo relacional em relagéo aos modelos de dados mais antigos so sua representagdo de dados simples e a facilidade com que mesmo consultas complexas podem ser expressas. Embora nos concentremos nos conceitos subjacentes, também apresentaremos os recursos da Data Definition Language (DDL — linguagem de definicéo de dados) da SQL, a linguagem padrao para criar, manipular e consultar dados em um SGBD relacional. Isso nos permite basear a discussao firmemente em termos de sistemas de banco de dados re Discutiremos 0 conceito de relagao na Seco 3.1 e mostraremos como se faz para criar relacdes usando a linguagem SQL. Um componente importante de um modelo de dados 0 conjunto de construtores que ele fornece para especificar as condigdes que devem ser satisfeitas pelos dados. Tais condigdes, chamadas restricdes de integridade (Ris), permitem que 0 SGBD rejeite operagdes que poderiam corromper os dados. Apresentaremos as restrigdes de integridade no modelo relacional na Segdo 3.2, junto com uma discussio sobre o suporte da SQL para Ris. Discutiremos como um SGBD impée restrigdes de integridade na Seco 3.3. Na Seco 3.4, examinaremos 0 mecanismo para acessar e recuperar dados do banco de dados, as linguagens de consulta, e apresentaremos os recursos de consulta da SQL, os quais examinaremos com mais detalhes em capitulo posterior.50 Capiruto 3 Em seguida, discutiremos a conversaéo de um diagrama ER em um esquema de banco de dados relacional, na Seciio 3.5. Apresentaremos as visdes ou tabelas definidas usando consultas, na Segdo 3.6. As visées podem ser usadas para definir 0 esquema externo de um banco de dados e, assim, fornecer o suporte para a independéncia légica dos dados no modelo relacional. Na Secao 3.7, descreveremos os comandos SQL para destruir e alterar tabelas e visdes. Finalmente, na Secao 3.8, estenderemos nosso estudo de caso de projeto, a loja na Internet apresentada na Sedo 2.8, mostrando como o diagrama ER de seu esquema conceitual pode ser mapeado para o modelo relacional e como 0 uso de visées pode ajudar nesse projeto. 3.1 INFRODUGAO AO MODELO RELACIONAL O principal construtor para representar dados no modelo relacional é a relagéo. Uma relacdo consiste em um esquema de relacio e em uma instancia de relagao. A instancia de relagdo € uma tabela, e 0 esquema de relagdo descreve os cabecalhos de coluna da tabela, Primeiro, descreveremos 0 esquema de relag&o e depois a instancia de relacao. O esquema especifica 0 nome da relagdo, 0 nome de cada campo (ou coluna ou atri- buto) ¢ 0 dominio de cada campo. Um dom{nio 6 descrito em um esquema de relagio pelo nome de dominio ¢ tem um conjunto de valores associados. Usaremos 0 exemplo das informagées de alo em um banco de dados de uma uni- versidade, do Capitulo 1, para ilustrarmos as partes de um esquema de relacao: Alunos (id-aluno: string, nome: string, login: string, idade: integer, média: real) Isso informa, por exemplo, que 0 campo chamado id-aluno tem um dominio deno- minado string. O conjunto de valores associados ao domfnio string ¢ 0 conjunto de todas as strings de caracteres. Agora, veremos as instancias de uma relagao. Uma instancia de uma relagdo é um conjunto de tuplas, também chamadas registros, no qual cada tupla tem o mesmo mimero de campos que o esquema de relacdo. Uma insténcia de relaco pode ser considerada uma. tabela na qual cada tupla é uma linha e todas as linhas tém o mesmo ntimero de campos. (O termo insténcia de relagéo é freqiientemente abreviado apenas como relagdo, quando nao ha confusdo com outros aspectos de uma relagéio, como seu esquema.) Uma instancia da relacéo Almos aparece na Figura 3.1. A insténcia Al contém seis tuplas e, conforme esperévamos, com base no esquema, ela tem cinco campos Note que nao existem duas linhas idénticas. Isso é um requisito do modelo relacional — ada relacio é definida como um conjunto de tuplas ou linhas tinicas. CAMPOS (ATRIBUTOS, COLUNAS) Nomes de campo et We in id-aluno | nome login idade| média 50000 [Dave |dave@es 19 [33 ruptas /f 53666 [Jones |jonestes 1s [3.4 (REGISTROS, (P_53688 [Smith |smith@ee frame (rata) LINHAS) \f 53650 [Smith [smithGmath 19 | 38 53831_|Madayan|madayan@music| 11 18 53832 [Guldu_ |guldu@music_ | 12 | 2.0 Figura 3.1 Uma instancia Al da relacéo Alunos.O Modelo Relacional 51 Na pratica, os sistemas comerciais permitem que as tabelas tenham linhas duplica- das, mas supomos que uma relagao é mesmo um conjunto de tuplas, a niio ser que seja mencionado de outra forma. A ordem na qual as linhas sao listadas nao é importante. A Figura 3.2 mostra a mesma instancia de relag&o. Se os campos séo nomeados, como em nossas definigdes de esquema e figuras representando instancias de relacao, a or- dem dos campos também nao importa. Entretanto, uma convengao alternativa é listar 08 campos em uma ordem especifica e referir-se a um campo por sua posicao. Assim, id-aluno é 0 campo 1 de Alunos, login 6 o campo 3 e assim por diante. Se essa conven- cao for usada, a ordem dos campos teré significado. A maioria dos sistemas de banco de dados usa uma combinagao dessas convengoes. Por exemplo, na SQL, a convencio dos campos nomeados é usada em instrugdes que recuperam tuplas, e a convengdo dos campos ordenados comumente usada ao se inserir tuplas. id-aluno [nome login idade | média 53831 _|Madayan|madayan@music| 11 | 18 53832 _[Guldu_ | guldu@music 2 | 20 53688 [Smith _|smith@ce i [E8@ 53650 [Smith | smith@math 19 | 38 53666 [Jones | jones@es is | 34 50000 |Dave | dave@es ig | 33 Figura 3.2 Uma representacio alternativa da instancia Al de Alunos. Um esquema de relagao especifica 0 dominio de cada campo ou colina na instancia de relagao, Essas restrigdes de dominio no esquema especificam uma condigéo impor- tante que queremos que cada instancia da relagdo satisfaca: os valores que aparecem em uma coluna devem ser extraides do dominio associado a essa coluna. Assim, em termos de linguagem de programagiio, 0 dominio de um campo é basicamente o tipo desse campo e restringe os valores que podem aparecer no campo. Mais formalmente, seja R(/;:D1, ..., f,:Dn) um esquema de relacdo, e para cada f,, 1= 3,3 Se essa consulta for aplicada na instancia Al de Almos mostrada na Figura 3.1, obteremos a instancia que aparece na Figura 3.3. id-aluno | nome login idade | média 50000 | Dave dave@cs 19 3,2 53666 [Jones _| jones@cs cee ea 53688 [Smith | smith@ee i [84 53650 [Smith | smith@math ron ea 53831_|Madayan |madayan@music| 11 | 18 53832 |Guldu | guldu@music 12 | 20 Figura 3.3 Instancia 41 de Alunos apés a atualizagao. 3.2. RESTRICOES DE INTEGRIDADE SOBRE RELACOES Um banco de dados é tao bom quanto as informagées nele armazenadas e, portanto, um SGBD deve ajudar a evitar a entrada de informagées incorretas. Uma restrigio de integridade (RI) ¢ uma condicfo especificada sobre um esquema de banco de dados e limita os dados que podem ser armazenados em uma instancia do banco de dados. Se uma instancia do banco de dados satisfaz todas as restrigdes de integridade especifi- cadas em seu esquema, entao ela é uma instancia valida. Um SGBD impée restrigées de integridade, no sentido de que ele permite o armazenamento apenas de instancias validas no banco de dados. As restrigdes de integridade so especificadas e verificadas em diferentes ocasides: 1. Quando o administrador ou 0 usuario final define um esquema de banco de dados, cle especifica as RIs que devem valer em qualquer instancia desse banco de dados. 2. Quando um aplicativo de banco de dados é executado, 0 SGBD verifica se existem violagdes e profbe alteragdes nos dados que violem as Ris especificadas. (Em al- gumas situacdes, em vez de proibir a alteracio, o SGBD poderia fazer algumas alteracbes de compensagao nos dados, para garantir que a instancia do banco de dados satisfaga todas as RIs. Em qualquer caso, ndo sao permitidas alteragdes no banco de dados para criar uma instancia que viole qualquer RI.) E importante es- pecificar exatamente quando as restrigdes de integridade sao verificadas, em relagao54 Capiruto 3 a instrugdo que causa a alteragio nos dados ¢ a transagao da qual ela faz parte. Discutiremos esse aspecto no Capitulo 16, apés apresentarmos com mais detalhes 0 conceito de transagao, introduzido no Capitulo 1. Muitos tipos de restrigdes de integridade podem ser especificados no modelo rela- cional. Jé vimos um exemplo de restricéo de integridade nas restri¢des de doménio associadas a um esquema de relacio (Segao 3.1). Em geral, outros tipos de restricdes também podem ser especificados; por exemplo, dois alunos néo podem ter o mesmo valor-de id-aluno. Nesta seco, discutiremos as restrigdes de integridade, além das restrigdes de dominio, que um administrador ou usuério de banco de dados pode espe- cificar no modelo relacional. 3.2.1 Restricdes de Chave Considere a relagao Alunos e a restrigo de que dois alunos néo podem ter a mesma identificagao. Essa RI ¢ um exemplo de restrig&o de chave. Uma restricéo de chave é uma declaragio de que certo subconjunto minimo dos campos de uma relagéio é um identificador tinico para’uma tupla. Um conjunto de campos que identifica uma tupla de acordo com uma restrigo de chave ¢ chamado chave candidata da relacio; freqtien- temente, abreviamos isso apenas como chave. No caso da relagaio Altmos, 0 (conjunto de campos contendo apenas 0) campo id-aluno é uma chave candidata. ‘Vamos analisar melhor a definigéo anterior de chave (candidata). Existem duas partes na definigéao:? 1. Duas tuplas distintas em uma insténcia valida (uma instancia que satisfaz todas as Rls, incluindo a restrigao de chave) n&io podem ter valores idénticos em todos os campos de uma chave. 2, Nenhum subconjunto do conjunto de campos em uma chave é um identificador tinico para uma tupla. A primeira parte da definigao significa que, em qualquer instancia valida, os valores nos campos de chave identificam univocamente uma tupla na instncia. Ao especificar uma restrigao de chave, o administrador ou usudrio do banco de dados deve certi- ficar-se de que essa restrig&o ndo o impega de armazenar um conjunto “correto” de tuplas. (Um comentario semelhante também se aplica a especificagao de outros tipos de Ris.) A nog&o de “correto” aqui depende da natureza dos dados que estao sendo armazenados. Por exemplo, varios alunos podem ter 0 mesmo nome, embora cada um tenha uma identificag&o tinica. Se o campo nome for declarado como uma chave, o SGBD nao permitira que a relagdo Alunos contenha duas tuplas descrevendo alunos diferentes com o mesmo nome! A segunda parte da definicao significa, por exemplo, que 0 conjunto de campos {id-aluno, nome} nao € uma chave para Alunos, pois esse conjunto contém a cha- ve {id-aluno}. O conjunto {id-aluno, nome} é um exemplo de superchave, que 6 um conjunto de campos que contém uma chave. Veja novamente a instancia da relagao Alumos na Figura 3.1. Observe que duas linhas diferentes sempre tém valores de id-aluno diferentes; id-aluno é uma chave e identifica uma tupla univocamente. Entretanto, isso nao vale para campos que nao sio chave. Por exemplo, a relacéo contém duas linhas com Smith no campo nome. 2 O termo chave é muito utilizado. No contexto dos métodos de acesso, falamos sobre chaves de pesquisa, que sfio muito diferentes,O Modelo Relacional 55, Note que 6 garantido que toda relagdo tenha uma chave. Como uma relagéio 6 um conjunto de tuplas, o conjunto de todos os campos ¢ sempre uma superchave. Se outras restricdes valem, algum subconjunto dos campos pode formar uma chave, do contrério 0 conjunto de todos os campos é uma chave. Uma relacio pode ter varias chaves candidatas. Por exemplo, os campos login e idade da relagéo Alunos, em conjunto, também podem identificar alunos de maneira tinica. Ou seja, {login, idade} também 6 uma chave. Pode parecer que login 6 uma chave, pois nao existem duas lifhas no exemplo de instancia que tenham o mesmo valor de login. Entretanto, a chayve deve identificar as tuplas univocamente em todas as instdncias vélidas posstveis da relac&io. Dizendo que {login, idade} 6 uma chave, 0 usuario esté declarando que dois alunos podem ter 0 mesmo login ou a mesma idade, mas nao ambos. ‘Além de todas as chaves candidatas dispontveis, um projetista de banco de dados pode identificar uma chave priméria. Intuitivamente, uma tupla pode ser referenciada em qualquer outra parte do banco de dados armazenando-se os valores de seus campos de chave priméria. Por exemplo, podemos nos referir a uma tupla de Alunos armaze- nando seu valor de id-aluno. Como conseqiiéncia dessa maneira de referéncia as tuplas de alunos, freqtientemente as tuplas siio acessadas especificando-se seu valor de id-alu- no. Em prinefpio, podemos usar qualquer chave, e nao apenas a chave priméria, para nos referirmos a uma tupla. Entretanto, usar a chave priméria ¢ preferivel, pois é ela que o SGBD espera — esse ¢ 0 significado de projetar uma chave candidata em par- ticular como chave primaria — e para a qual faz otimizagdes. Por exemplo, o SGBD pode criar um indice com os campos de chave priméria como chave de pesquisa, para tornar eficiente a recuperacao de wma tupla, dado seu valor de chave priméaria. A idéia da referéncia a uma tupla sera mais bem desenvolvida na prdxima seco. Especificando Restricdes de Chave em SQL Na SQL, podemos declarar que um subconjunto das colunas de uma tabela constituem uma chave, usando a restrig&éo UNIQUE. No méximo uma dessas chaves candidatas pode ser declarada como chave priméria, usando-se a restrigio PRIMARY KEY. (A SQL nfo exige que essas restrigdes sejam declaradas para uma tabela.) Vamos rever nosso exemplo de definig&o de tabela e especificar informagées de chave: CREATE TABLE Alunos (id-aluno CHAR (20), nome CHAR(30), login CHAR(20), idade INTEGER, média REAL, UNIQUE (nome, idade), CONSTRAINT Chave Alunos PRIMARY KEY (id-aluno) ) Essa definic&o diz que id-aluno 6 a chave priméria e a combinacio de nome e idade também 6 uma chave. A definigéo da chave priméria também ilustra como podemos nomear uma restrigao, precedendo-a com CONSTRAINT nome-da-restri¢ao. Se a restri- cio for violada, seu nome seré retornado e poder ser usado para identificar 0 erro. 3.2.2 Restricées de Chave Estrangeira As vezes, as informagdes armazenadas em uma relagio estao ligadas as informagées armazenadas em outra relagao. Se uma das relagées for modificada, a outra deverd ser verificada e, talvez, modificada, para manter os dados consistentes. Uma RI envolvendo56 CapfrLo 3 as duas relagdes devera ser especificada, caso um SGBD precise fazer tais verificagdes. A RI mais comum envolvendo duas relagées 6 uma restrig&io de chave estrangeira. Suponha que, além de Alunos, tenhamos uma segunda relacao: Matriculado(id-aluno: string, id-curso: string, nota: string) Para garantir que apenas estudantes legftimos possam se matricular nos cursos, qualquer valor que aparega no campo id-aluno de uma instancia da relagio Matricu- lado também deve aparecer/no campo id-aluno de alguma tupla na relagio Alunos. O campo id-aluno de Matri¢ulado 6 chamado chave estrangeira e se refere a Alunos. A chave estrangeira na relac&o de referéncia (Matriculado, em nosso exemplo) deve corresponder A chave primaria da relagio referenciada (Alunos); ou seja, ela deve ter 0 mesmo mimero de colunas e tipos de dados compativeis, embora os nomes das colunas possam ser diferentes. Essa restrig&o est ilustrada na Figura 3.4. Conforme mostra a figura, podem existir tuplas de Alunos que néo sejam referenciadas a partir de Matriculado (por exemplo, 0 alu- no com id-aluno=50000). Entretanto, todo valor de #d-aluno que aparece na instancia da tabela Matriculado aparece na coluna de chave priméria de uma linha na tabela Alunos. Chave estrangeira - Chave priméria id-curso _[notalid-aluno|—{id-aluno| nome login idade|média Carnaticl01 | C 50000 |Dave dave@cs 19 3,3 Reggae203_| B 753666 |Jones _|jones@cs 1s | 34 'Topologyl12} A 53688 |Smith smithGee 18 3,2 History105 B 53650 Smith smith@math i 3,8 53831 |Madayan |madayan@music | 11 18 53832 [Guldu —_ [guldu@music 12 | 20 Matriculado Alunos (relag&o que referencia) (relag&o referenciada) Figura 3.4 Integridade referencial. Se tentarmos inserir a tupla (55555, Art10}, A) em M1, a RI seré violada, pois nao hé nenhuma tupla em Al com d-aluno 55555; o sistema de banco de dados deve rejeitar essa insergdo. Analogamente, se excluirmos a tupla (59666, Jones, jones@ ¢3, 18, 3,4) de A1, violaremos a restrigao de chave estrangeira, pois a tupla (53666, History105, BY em M1 contém 0 valor de id-aluno 53666, 0 id-aluno da tupla de Alu- nos exclufda. O SGBD deve proibir a exclusdo ou, talvez, excluir também a tupla de Matriculado que referencia a tupla de Alunos excluida. Discutiremos as restrigdes de chave estrangeira e seu impacto sobre as atualizages na Segiio 3.3. Finalmente, notamos que uma chaye estrangeira poderia referenciar a mesma re- lagao. Por exemplo, poderfamos ampliar a relacio Alunos com uma coluna chamada parceiro e declarar essa coluna como uma chave estrangeira referindo-se a Alunos. Intuitivamente, cada aluno poderia ento ter um parceiro eo campo parceiro conteria 0 id-aluno do parceiro. O leitor observador sem dtivida perguntaré: “E se um aluno nao tiver (ainda) um parceiro?”. Essa situacio é tratada na SQL usando-se um valor especial chamado null. O uso de null em um campo de uma tupla significa que 0O Modelo Relacional 57 valor nesse campo é desconhecido ou nao é aplicdvel (por exemplo, nao conhecemos 0 parceiro ainda ou nao hé nenhum parceiro). A presenca de null em um campo de cha- ve estrangeira nao viola a restrigao de chave estrangeira. Entretanto, valores null néo podem aparecer em um campo de chave primaria (pois os campos de chave priméria sio usados para identificar uma tupla univocamente). Discutiremos melhor os valores null no Capitulo 5. Especificando Restrigdes de Chave Estrangeira em SQL Vamos definir Matriculado(id-aluno: string, id-curso: string, nota: string): CREATE TABLE Matriculado (id-aluno CHAR(20), id-curso CHAR (20), nota CHAR (10), PRIMARY KEY (id-aluno, id-curso), FOREIGN KEY (id-aluno) REFERENCES Alunos ) A restrig&éio de chave estrangeira diz que todo valor de id-aluno em Matriculado também deve aparecer em Alunos; ou seja, id-aluno em Matriculado 6 uma chave es- trangeira referenciando Alunos. Especificamente, todo valor de id-aluno em Matricu- lado deve aparecer como o valor do campo de chave primaria, id-aluno, de Alunos. A propésito, a restrigéo de chave primaria de Matriculado diz que um aluno tem exata- mente uma nota para cada curso em que esta matriculado. Se quisermos registrar mais de uma nota por aluno, por curso, devemos alterar a restrigio de chave priméria. 3.2.3 Restricdes Gerais As restrigdes de dominio, de chave priméria e de chave estrangeira sao consideradas parte fundamental do modelo de dados relacional e recebem atengao especial na maio- ria dos sistemas comerciais. As vezes, entretanto, 6 necessdrio especificar restrigdes mais gerais. Por exemplo, podemos exigir que a idade dos alunos esteja dentro de certo intervalo de valores; dada essa especificagio de RI, o SGBD rejeitara as insergées e atualizagoes que violarem a restricdo. Isso ¢ muito titil na prevengao de erros de entrada de dados. Se especificarmos que todos os alunos devem ter pelo menos 16 anos, a instancia de Alunos mostrada na Figura 3.1 seré invalida, pois dois alunos tem idade menor do que essa. Se proibirmos a inserg&o dessas duas tuplas, teremos uma instancia valida, como se vé na Figura 3.5. id-aluno | nome login idade | média 53666 | Jones | jones@cs 18 34 53688 |Smith |smith@ee 18 3,2 53650 | Smith a 19 38 Figura 3.5 Uma instancia A2 da relagao Alunos, ‘A RI que diz que os alunos devem ser maiores de 16 anos pode ser considerada uma restric&io de dominio estendida, pois estamos basicamente definindo 0 conjunto de valores de idade permitidos de maneira mais restrita do que é possivel usando simples- mente um dominio padrao, como integer. Em geral, contudo, podem ser especifica-58 Captruto 3 das restriges que vio bem além das de dominio, de chave e de chave estrangeira. Por exemplo, poderiamos exigir que todo aluno cuja idade fosse maior do que 18 devesee ter uma média maior do que 3. Os sistemas de banco de dados relacionais atuais suportam essas restrigdes gerais na forma de restrigées de tabela e assertivas. As restrigdes de tabela sio asvoviedas uma tinica tabela e verificadas quando essa tabela é modificada. Em contraste, as av. sertivas envolvem varias tabelas e sio verificadas quando qualquer uma dessas taboles € modificada. Tanto as restrigdes de tabela como as assertivas podem usar o poder to- tal das consultas SQL para especificar a restriefio desejada, Discutiremos o suporte da SQL para restrigdes de tabéla e assertivas na Segéo 6.7, pois uma avaliagio completa de seu poder exige um both entendimento dos recursos de consulta da SQL. 3.3 VERIFICANDO RESTRICOES DE INTEGRIDADE Conforme observamos anteriormente, as Rls so especificadas quando uma relagio € ariada e verificadas quando uma relagio € modificada. O impacto das restrigdes de dominio, PRIMARY KEYe UNIQUE é simples de entender: se um comando de insercao, exclusdo ou atnalizagio causa uma violacéo, ele ¢ rejeitado. Toda violacio de Rl em Potencial geralmente ¢ verificada no final da execuco de cada instrugéio SQL, embora Possa ser adiada até o final da transagdo que esta executando a instrugdo, conforme veremos na Segio 3.3.1. Considere a instancia A1 de Alumnos mostrada na Figura 3.1. A insergio a seguir viola a restrigiio de chave primaria, porque jé existe uma tupla com id-aluno 53688, ¢ sera rejeitada pelo SGBD: INSERT INTO Alunos (id-aluno, nome, login, idade, media) VALUES (53688, ‘Mike’, ‘mike@ee’, 17, 3,4) A insergéo a seguir viola a restrig&o de que a chave primaria nao pode conter nul: INSERT INTO Alunos (id-aluno, nome, login, idade, media) VALUES (null, ‘Mike’, ‘mike@ee’, 17, 3,4) E claro que surge um problema semelhante quando tentamos inserir uma tupla com um valor em um campo que nao esteja no dominio associado a esse campo; isto & quando violamos uma restrigéio de dominio. A exclusio de tuplas nao cause wine violagio de restrigdes de dominio, chave primaria ou exclusiva, Entretanto, uma atua- Nzagao pode causar violagées semelhantes a uma insergio: UPDATE Alunos A SET A.id-aluno WHERE A.id-aluno 50000. 53688 Essa atualizagao viola a restrigdo de chave primaria, pois jé existe uma tupla com id-aluno 50000. O impacto das restrigdes de chave estrangeira 6 mais complexo, pois as vezes a SQL tenta retificar uma violagao de restrigao de chave estrangeira, em vez de simplesmente rejeitar a alteragao. Discutiremos as etapas de verificagio da integridade referencial executadas pelo SGBD em termos de nossas tabelas Matriculado e Alunos, com a Testricao de chave estrangeira de que Matriculado.id-aluno é uma referencia para (a chave priméria de) Alunos.O Modelo Relacional 59. Além da instiancia Al de Alunos, considere a instncia de Matriculado mostrada na Figura 3.4. As exclusdes de tuplas de Matriculado nfo violam a integridade referen- cial, mas as insergdes de tuplas de Matriculado poderiam violar. A insergdo a seguir 6 invélida, pois no hé nenhuma tupla de Alunos com id-aluno 51111: INSERT INTO Matriculado (id-curso, nota, id-aluno) VALUES (‘Hindil01’, ‘B’, 51111) Por outro lado, insergdes de tuplas em Alunos nao violam a integridade referencial, € as exclusdes poderiam causar violacdes. Além disso, atualizagdes em Matriculado on em Alunos que alteram o valor de id-aluno (respectivamente, id-aluno) poderiam violar a integridade referencial. ‘A SQL fornece varias manciras alternativas de tratar de violagdes de chave estran- geira. Devemos considerar trés perguntas basicas: 1. O que devemos fazer se uma linha de Matriculado é inserida, com um valor na coluna id-aluno que nao aparece em nenhuma linha da tabela Alunos? Nesse caso, o comando INSERT é simplesmente rejeitado. 2. O que devemos fazer se wma linha de Alunos é exclutda? ‘As opcdes sf « Excluir todas as linhas de Matriculado que referenciam a linha de Alinos excluida. + Proibir a exclusdo da linha de Alunos, caso uma linha de Matriculado a refe- rencie, + Configurar a coltma id-aluno com o valor de id-aluno de algum alino (existen- te) “padrao”, para cada linha de Matriculado que referencie a linha de Alunos exclufda. Para cada linha de Matriculado que referencia a linha exclufda, configurar a coluna id-aluno como null. Em nosso exemplo, esta opcio entra em conflito com 0 fato de que id-aluno faz parte da chave priméria de Matriculado e, por- tanto, nao pode ser configurada como null, Assim, em nosso exemplo estamos limitados as trés primeiras opgdes, embora esta quarta opgao (configurar a chave estrangeira como null) esteja disponivel em geral. 3. O que devemos fazer se o valor da chave priméria de uma linha de Alunos for atualizada? As opgdes aqui so semelhantes as do caso anterior. A SQL nos permite escolher qualquer uma das quatro opgdes em DELETE e UPDA~ TE. Por exemplo, podemos especificar que, quando uma linha de Alunos é exclufda, to- das as linhas de Matriculado que se referem a ela também devem ser excluidas, mas que, quando a coluna id-aluno de uma linha de Alinos é modificada, essa atualizagao deve ser rejeitada, caso uma linha de Matriculado se refira linha de Alunos modificada: CREATE TABLE Matriculado ( id-aluno CHAR (20), id-curso CHAR (20), nota CHAR (10), PRIMARY KEY (id-aluno, id-curso), FOREIGN KEY (id-aluno) REFERENCES Alunos ON DELETE CASCADE ON UPDATE NO ACTION )60 Cariruto 3 As opgées so especificadas como parte da declaragao da chave estrangeira. A op- g&o padraéo 6 NO ACTION, que significa que a agéo (DELETE ou UPDATE) deve ser rejeitada. Assim, em nosso exemplo, a cléusula ON UPDATE poderia ser omitida, com o mesmo efeito. A palavra-chave CASCADE diz que, se uma linha de Alunos for excluida, todas as linhas de Matriculado que se referem a ela também serao excluidas. Se a claéu- sula UPDATE especificasse CASCADE e a coluna id-aluno de uma linha de Alunos fosse atualizada, essa atualizagio também seria executada em cada, linha de Matriculado que se referisse 4 linha de Alunos atualizada. Se uma linha de Alunos for excluida, podemos trocar a matricula para um alu- no ‘padrao’, usando ON DELETE SET DEFAULT. O aluno padrao é especificado como parte da definigéo do campo id-aluno em Matriculado; por exemplo, éd-aluno CHAR (20) DEFAULT ‘53666’. Embora a especificagao de um valor padrao seja apro- priada em algumas situagdes (por exemplo, um fabricante de pecas padrao, caso um fabricante em particular saia do ramo), no é adequado trocar as matriculas para um aluno padrao. A solugao correta nesse-exemplo é excluir também todas as tuplas de matricula do aluno exclufdo (isto 6, CASCADE) ou rejeitar a atualizagio. A SQL também permite 0 uso de null como valor padrao, especificando-se ON DE- LETE SET NULL. 3.3.1 Transacées e Restricées Conforme vimos no Capitulo 1, um programa executado em um banco de dados é cha- mado transacéo ¢ pode conter varias instrugdes (consultas, insergdes, atualizagées etc.) que acessam o banco de dados. Se (a execucao de) uma instrugiio em uma transagio violar uma restrigo de integridade, o SGBD deveria detectar isso imediatamente, ou todas as restriges deveriam ser verificadas em conjunto, imediatamente antes que a transagdo termine? Por padrao, uma restrig&o é verificada no final de cada instrugdo SQL que possa levar a uma violagao e, se houver violacio, a instrug&o serd rejeitada. As vezes essa estratégia ¢ inflexivel. Considere as variantes das relagdes Alunos e Cursos a seguir; todo aluno é obrigado a ter um curso de distingo, todo curso 6 obrigado a ter um monitor, que é algum aluno. CREATE TABLE Alunos ( id-aluno CHAR (20), nome CHAR (30), login CHAR (20), idade INTEGER, distingo CHAR(10) NOT NULL, media REAL ) PRIMARY KEY (id-aluno), FOREIGN KEY (distingao) REFERENCES Cursos (id-curso) CREATE TABLE Cursos ( id-curso CHAR(10), nomec CHAR (10), créditos INTEGER, monitor CHAR(20) NOT NULL, PRIMARY KEY (id-curso) FOREIGN KEY (monitor) REFERENCES Alunos (id-aluno)) Quando uma tupla de Alunos é inserida, é feita uma verificagdo para saber se o curso de distingao est na relacdio Cursos e, quando uma tupla de Cursos é inserida,O Modelo Relacional 61 6 feita uma verificacéio para saber se o monitor esté ua relagdo Alunos. Como vamos inserir a primeira tupla de curso ou de aluno? Uma nao pode ser inserida sem a outra. A (nica maneira de realizar essa insergéio ¢ adiando a verificacao da restrigao, que normalmente seria feita no final de uma instrugéo INSERT. A SQL permite que uma restricdo esteja no modo DEFERRED ou IMMEDIATE. SET CONSTRAINT nome-restrigaéo DEFERRED Uma restrigéo no modo adiado (deferred) € verificada no momento da cfetivacio da transagdo (commit). Em nosso exemplo, as restrigdes de chave estrangeira sobre Alunos e Cursos podem ambas ser declaradas no modo adiado. Podemos entao inserir um aluno com um curso de distingiio inexistente (tornando o banco de dados tempora- riamente inconsistente), inserir o curso (restaurando a consisténcia) e depois efetivar e verificar se as duas restrigdes sao satisfeitas. 3.4 CONSULTANDO DADOS RELACIONAIS Uma consulta de banco de dados relacional (abreviadamente, consulta) é uma pergun- ta sobre os dados, e a resposta consiste em uma nova relagao contendo o resultado. Por exemplo, poderfamos querer encontrar todos os alunos com menos de 18 anos ou todos os alunos matriculados em Reggae203. Uma linguagem de consulta é uma linguagem especializada para escrever consultas. ‘A SQL a lingnagem de consulta comercial mais popular para um SGBD relacio- nal. Apresentaremos agora alguns exemplos de SQL que ilustram como as relagdes podem ser facilmente consultadas. Considere a instancia da relagio Alunos mostrada na Figura 3.1. Podemos recuperar as linhas correspondentes aos alunos que tém menos de 18 anos com a seguinte consulta SQL: SELECT * FROM = Alunos A WHERE A.idade < 18 O simbolo “*’ significa que manteremos no resultado todos os campos das tuplas selecionadas. Considere A uma varidvel que assume o valor de cada tupla em Alunos, uma tupla apés a outra. A condigaéo A.idade < 18 na cléusula WHERE especifica que queremos selecionar apenas as tuplas nas quais 0 campo idade tem um valor menor do que 18. Essa consulta retorna a relagéo mostrada na Figura 3.6. id-aluno | __nome login idade | média 53831_| Madayan | madayan@music | 11 | 18 53832 [Guldu | guidu@music 12 | 20 Figura 3.6 Alunos com idade < 18 na instancia Al. Esse exemplo ilustra que o domfnio de um campo restringe as operagdes permitidas em seus valores, além de restringir os valores que podem aparecer no campo. A condi- So Avidade < 18 envolve uma comparagio aritmética de um valor de idade com um inteiro e é permitida, pois o dominio de idade é 0 conjunto dos mtimeros inteiros. Por outro lado, uma condigéo como A.idade = A.id-aluno nao faz sentido, pois compara62 Capiruto 3 um valor inteiro com um valor de string e essa comparagio 6 definida como falha na SQL; uma consulta contendo essa condicéo nio produz nenhuma tupla de resposta. Alem de selecionar um subconjunto de tuplas, uma consulta pode extrair um eub- conjunto dos campos de cada tupla selecionada. Podemos obter os nomes e logins dos alunos com menos de 18 anos, com a seguinte consulta: SELECT A.nome, A.login FROM Alunos A WHERE A.idade < 18 A Figura 3.7 mostra a resposta dessa consulta; ela 6 obtida pela aplicacdo da sele- sao na instéincia Al de Almos (para obter a relagéo mostrada na Figura 3.6), segnida da remogio dos campos indesejados. Note que a ordem na qual executamos ossas operagées importa — se removermos os campos indesejados primeiro, nio poderemos verificar a condigio A.idade < 18, que envolve um desses campos. [nome login ra Se Madayan | madayanO@music Guldu_—_[guldu@music Figura 3.7 Nomes ¢ logins dos alunos com menos de 18 anos. Também podemos combinar informagées das relagdes Alunos e Matriculado. Se quiséssemos obter os nomes de todos os alunos que obtiveram A ea identificagéo do curso em que tiraram A, poderfamos escrever a seguinte consulta: SELECT A.nome, M.id-curso FROM — Alunos A, Matriculado M WHERE — A.id-aluno = M.id-aluno AND M.nota = ‘A’ Essa consulta pode ser entendida como segue: “Se houver uma tupla A de Alunos © uma tupla M de Matriculado, tal que A.id-aluno = M.id-aluno (de modo que A dos. creve o aluno matriculado em M) e M.nota = ‘A’, entéo, imprima o nome do aluno ¢ a identificagdo do curso”. Quando avaliada nas instancias de Alunos e Matriculado da Figura 3.4, essa consulta retorna uma tnica tupla, (Smith, Topology112). Abordaremos as consultas relacionais e a SQL com mais detalhes em capftulos subseqiientes. 3.5 PROJETO LOGICO DO BANCO DE DADOS: ER PARA RELACIONAL © modelo ER € conveniente para representar um projeto de banco de dados inicial de alto nivel. Dado um diagrama ER descrevendo um banco de dados, 6 adotada uma estratégia padréo para gerar um esquema de banco de dados relacional que se aproxima muito do projeto ER. (A transformacao ¢ aproximada até o ponto em que nao podemos capturar todas as restrigées implicitas no projeto ER usando SQL, a néio ser que usemos certas restriges da SQL que séio dispendiosas para verificar.) Descreveremos agora como se faz para transformar um diagrama ER em uma cole.O Modelo Relacional 63 cio de tabelas com restrigées associadas; ou seja, um esquema de banco de dados relacional. 3.5.1 Conjuntos de Entidades para Tabelas Um conjunto de entidades 6 mapeado em uma relag&o de maneira direta: cada atributo do conjunto de entidades torna-se um atributo da tabela. Note que co- nhecemos os domfnios de cada atributo e a chave (priméria) de um conjunto de entidades. Considere 0 conjunto de entidades Funcionarios com atributos epf, nome e vaga, mostrado na Figura 3.8. Uma possfvel instancia do conjunto de entidades Funcio- nérios, contendo trés entidades de Funcionérios, aparece na Figura 3.9 em formato tabular. Funcionérios Figura 3.8 O conjunto de entidades Funcionarios. oof nome | vaga 123-22-3666 | Attishoo 48 231-31-5368 | Smiley 22 131-24-3650 |Smethurst | 35 Figura 3.9 Uma instancia do conjunto de entidades Funcionstios. A instrugéo SQL a seguir captura as informacées anteriores, incluindo as restrigdes de dominio e as informagées de chav CREATE TABLE Funciondrios ( cpf CHAR (11), nome CHAR (30), vaga, INTEGER, PRIMARY KEY (cpf) ) 3.5.2 Conjuntos de Relacionamentos (sem Restrigdes) para Tabelas Assim como um conjunto de entidades, um conjunto de relacionamentos ¢ mapeado em uma relac&io no modelo relacional. Comegamos considerando conjuntos de relacio- namentos sem restrigdes de chave e de participagio, e discutiremos como se faz para tratar de tais restricdes em secdes subseqitentes. Para representarmos um relaciona- mento, devemos identificar cada entidade participante e fornecer valores para os atri- butos descritivos do relacionamento. Assim, os atributos da relagdo incluem:64 Captruto 3 » Os atributos da chave priméria de cada conjunto de entidades participante, como campos de chave estrangeira. « Os atributos dest vos do conjunto de relacionamentos O conjunto de atributos nfo descritivos é uma superchave para a relaciio. Se nao houver restrigdes de chave (consulte a Segiio 2.4.1), esse conjunto de atributos sera uma chave candidata. Considere o conjunto de relacionamentos Trabalha_em?2 mostrado na Figura 3.10. Cada departamento tem escritérios em varios locais e queremos registrar os locais em que cada funciondrio trabalha. Funciontos |-—— ==) Localidades =>) Figura 3.10 Um conjunto de relacionamentos ternario. Rome-depto| ‘Trabalha_omd Departamentos informacées disponfveis sobre a tabela Trabalha_em2 sio capturadas pela seguinte definicao SQL: CREATE TABLE Trabalha_em2 (cpf CHAR (11), id-depto INTEGER, enderego CHAR(20) , desde DATE, PRIMARY KEY (cpf, id-depto, endereco), FOREIGN KEY (cpf) REFERENCES Funciondrios, FOREIGN KEY (enderego) REFERENCES Localidades, FOREIGN KEY (id-depto) REFERENCES Departamentos ) Note que os campos enderego, id-depto e cpf nio podem receber valores null. Como esses campos fazem parte da chave primaria de Trabalha_em2, uma restrigéio NOT NULL est implicita para cada um deles. Essa restrigdo garante que esses campos iden- tifiquem univocamente um departamento, um funcionario e um local em cada tupla de Trabalha_em2. Também podemos especificar que uma agdo em particular é desejada quando uma tupla referenciada de Funciondrios, Departamentos ou Localidades é ex- clufda, conforme explicado na discussio sobre restrigdes de integridade da Segdo 3.2. Neste capitulo, supomos que a aco padrao é apropriada, exceto para situagdes nas quais a seméntica do diagrama ER exige alguma outra acio. Finalmente, considere 0 conjunto de relacionamentos Reporta_a, mostrado na Fi- gura 3.11. Os indicadores de papel supervisor e subordinado sio usados para criar nomes de campo significativos na instrugéio CREATE da tabela Reporta_a: fae inven