Banco de Dados A. Saade Pagani & A. L.

Pagani

Banco de Dados

1.68

ndice
1 Introduo...............................................................................................................................................4 1.1 Um pouco de histria...........................................................................................................................4 1.2 Conceitos bsicos..................................................................................................................................6 1.3 Exerccios..............................................................................................................................................8 2 Modelo conceitual de dados ..................................................................................................................9 2.1 Cardinalidade dos relacionamentos.................................................................................................11 2.2 Auto-relacionamento ........................................................................................................................14 2.3 Atributos ............................................................................................................................................14 2.3.1 Atributos do relacionamento ........................................................................................................15 2.4 Agregao ..........................................................................................................................................16 2.4.1 Restries para o uso da agregao ..............................................................................................18 2.5 Generalizao e Especializao........................................................................................................18 2.6 Dicas para a criao do Diagrama de Entidades e Relacionamentos...........................................20 2.7 Exerccios............................................................................................................................................20 3 Estudo de caso (parte 1).......................................................................................................................21 3.1 Relatrio da anlise............................................................................................................................22 3.2 Estudo de caso modelo conceitual de dados.................................................................................22 4 Modelos lgicos de dados......................................................................................................................27 4.1 Modelo hierrquico............................................................................................................................28 4.2 Modelo em rede..................................................................................................................................31 4.3 Modelo relacional...............................................................................................................................32 4.1 Exerccios............................................................................................................................................34 5 Projeto de banco de dados relacional..................................................................................................34 5.1 Chaves.................................................................................................................................................34 5.1.1 Restries de integridade...............................................................................................................36 5.1.2 Exerccios.........................................................................................................................................37 5.2 Normalizao......................................................................................................................................37 5.2.1 Primeira forma normal..................................................................................................................38 5.2.2 Dependncia funcional....................................................................................................................40 5.2.3 Segunda forma normal...................................................................................................................41 5.2.4 Terceira forma normal...................................................................................................................42 5.2.5 Outras formas normais...................................................................................................................44 5.2.6 Roteiro para a normalizao das tabelas......................................................................................44 5.2.7 Exerccios.........................................................................................................................................44 6 Estudo de caso (parte 2) Modelo lgico de dados............................................................................45 7 SQL.........................................................................................................................................................48 7.1 Elementos da linguagem SQL...........................................................................................................48 7.1.1 Palavras-chaves...............................................................................................................................49 7.1.2 Comandos........................................................................................................................................49 7.1.3 Tipos de dados.................................................................................................................................50 7.1.4 Operadores......................................................................................................................................50 7.2 Notao................................................................................................................................................51 7.3 SQL como linguagem de definio de dados...................................................................................51 7.3.1 Criao de tabelas...........................................................................................................................51 7.3.2 Eliminao de tabelas.....................................................................................................................51 7.4 SQL como linguagem de manipulao de dados.............................................................................52 7.4.1 Acesso aos dados de uma tabela....................................................................................................52 7.4.2 Trabalhando com mais de uma tabela simultaneamente............................................................53 7.4.2.1 Qualificadores e apelidos.............................................................................................................53 7.4.2.2 Encadeamento incondicional......................................................................................................54 7.4.2.3 Encadeamento condicional..........................................................................................................55 7.4.2.4 Encadeamento natural.................................................................................................................56 7.4.2.5 Encadeamento no simtrico......................................................................................................57 7.4.2.6 Encadeamento com mais de duas tabelas..................................................................................57 7.4.3 Insero de dados em uma tabela..................................................................................................57 7.4.4 Modificao dos dados de uma tabela...........................................................................................58 7.4.5 Eliminao de linhas de uma tabela..............................................................................................58 7.4.6 Um pouco mais sobre a clusula where........................................................................................59 7.4.7 Exerccios.........................................................................................................................................61

Banco de Dados

2.68

8 Modelo fsico de dados..........................................................................................................................61 8.1 Vises...................................................................................................................................................62 9 Estudo de caso (parte 3) Modelo fsico de dados.............................................................................63 10 Bancos de dados distribudos e arquitetura cliente/servidor..........................................................66 10.1 Bancos de dados distribudos..........................................................................................................66 10.2 Arquitetura cliente/servidor...........................................................................................................66 Bibliografia................................................................................................................................................67

Banco de Dados

3.68

1 Introduo
Nos primrdios da informtica, numa poca em que a utilizao de computadores para processar dados ainda no era chamada de informtica, os programas serviam para resolver apenas problemas cientficos. A grande maioria dos problemas cientficos tinha caractersticas comuns: poucos dados de entrada e de sada e grande quantidade de clculos (posteriormente os computadores foram aplicados para a soluo de problemas cientficos que manipulam grandes quantidades de dados). Assim sendo, havia pouca necessidade de armazenar dados. O que era muito bom para a poca, pois no havia muitos recursos para armazenar dados (os discos ainda no haviam sido inventados). Com a evoluo do computador outras aplicaes foram sendo desenvolvidas. Novas aplicaes requerendo novos e melhores recursos, novos recursos possibilitando a criao de novas aplicaes. E continuamos nisso at hoje.

1.1 Um pouco de histria

Os nicos dispositivos de entrada e sada de dados dos primeiros computadores eram dispositivos seqenciais: leitora de cartes, impressora e perfuradora de cartes. Desta maneira, a nica forma de armazenar permanentemente os dados para que eles pudessem servir de entrada para outro programa era perfur-los em cartes. Mais tarde surgiram os primeiros dispositivos magnticos para armazenamento permanente de dados: as fitas magnticas (tambm um dispositivo seqencial). J nesta poca os programadores comearam a perceber um problema: a descrio dos dados manipulados pelo programa ficava dentro do prprio programa. Algo como a declarao das variveis em um programa escrito em Pascal: var funcionario: record id_funcionario: string[6]; nome_funcionario: string[30]; salario: real; end; Era necessrio um controle rigoroso para evitar erros. Todos os programas que usavam um determinado conjunto de dados (um determinado arquivo) tinham que usar rigorosamente a mesma descrio para aqueles dados. Se um determinado campo de dados precisasse ser alterado (se um campo contendo o nome de uma pessoa precisasse ser aumentado, por exemplo) todos os programas que usavam o arquivo que contivesse esse campo, mesmo que no usasse o campo, precisavam ser alterados. D para imaginar o transtorno... (recentemente vimos algo semelhante com o famoso bug do milnio). Esse problema ficou conhecido como dependncia de dados, significando o forte relacionamento entre os programas e a descrio dos dados manipulados pelos programas. A soluo deste problema foi um dos primeiros motivadores para a criao da tecnologia de banco de dados. Muito se caminhou desde as primeiras tentativas de soluo (ainda sem usar bancos de dados) at a situao atual. Uma das primeiras alternativas tentadas foi retardar a incluso da descrio dos arquivos nos programas at o instante da compilao do programa. A coisa funcionava da seguinte forma: para cada arquivo era criada uma nica descrio que era mantida Banco de Dados 4.68

separada dos programas e cada programa que utilizasse aquele arquivo efetuava a incluso da descrio do arquivo correspondente durante a fase de compilao do programa. Vamos exemplificar fazendo uma analogia com um programa escrito na linguagem Pascal. Consideremos o programa a seguir, onde foram omitidas todas as partes que no so essenciais para o nosso exemplo: program exemplo; var funcionario: record id_funcionario: string; nome_funcionario: string; salario: real; end; begin ... end. Neste exemplo estamos considerando que a varivel funcionario corresponde descrio do registro do arquivo funcionario, que contm os dados dos funcionrios. Na implementao desta alternativa, a declarao da varivel funcionario seria codificada em um arquivo separado. Cada programa que precisasse trabalhar com o arquivo funcionario, no lugar da declarao da varivel funcionario, como acima, usaria um comando semelhante a: #include funcionario e o programa se transformaria em: program exemplo; #include funcionario begin ... end. No lugar do compilador usado normalmente para a linguagem Pascal, seria usada uma verso alterada, que teria como funo efetuar a substituio dos comandos #include pelos trechos correspondentes antes de iniciar a compilao do programa. O processo de substituio ocorria antes de iniciar o processo de compilao e, por isso, dava-se a um comando do tipo do comando #include o nome de comando de prprocessador (quem conhece a linguagem C e suas derivadas deve estar reconhecendo o comando... vem daquela poca). Portanto, para usar um arquivo, bastava inserir no local apropriado do programa o comando para efetuar a incluso da sua descrio e compilar o programa. Cada vez que o programa era compilado, usava a verso mais recente da descrio. Quando ocorria uma alterao na descrio de um arquivo, bastava que os programas que utilizassem aquele arquivo fossem novamente compilados. Entretanto, era preciso que todos os programas que usassem o arquivo fossem compilados com a nova verso. E era preciso ter um bom controle sobre isso, uma vez que no havia meio de obrigar e garantir tal fato (ainda no havia sistemas de controle automtico de verses). Mas j foi um bom comeo.

Banco de Dados

5.68

A partir deste pequeno passo, evolumos bastante, tanto do ponto de vista prtico como do ponto de vista terico. Por um lado, temos os Sistemas Gerenciadores de Bancos de Dados (SGBD), cada vez mais seguros, melhores e com mais recursos. Por outro lado, temos uma teoria, que avana cada vez mais, para nos auxiliar a projetar e implementar de forma cada vez mais rpida, fcil e segura, os bancos de dados necessrios para as nossas aplicaes, sejam elas pequenas aplicaes mono-usurio para um computador pessoal funcionando isoladamente, at grandes e complexas aplicaes para milhares de usurios simultneos utilizando computadores dos mais diversos tamanhos ligados em rede. Os SGBD partiram do pioneiro IMS da IBM (Information Management System da IBM, primeiro gerenciador de banco de dados) chegando hoje aos bancos de dados relacionais e caminhando para os bancos de dados baseados em objetos. Com relao ao projeto do banco de dados partimos da descrio de arquivos para atender a uma nica aplicao at chegarmos ao conceito de modelagem de dados ao nvel conceitual independente das aplicaes, cujo exemplo mais popular hoje o Modelo de Entidades e Relacionamentos (MER). Ao longo deste trabalho procuraremos, sempre que possvel, apresentar o contexto em que ocorreu cada mudana, para tornar mais fcil a compreenso do sentido e dos motivos de determinada evoluo.

1.2 Conceitos bsicos

Antes de entrar no assunto propriamente dito, vamos enumerar alguns conceitos para facilitar o entendimento da parte restante. Um Sistema Gerenciador de Banco de Dados (SGBD em portugus ou DBMS Data Base Management System em ingls) o conjunto integrado de programas usado no controle do armazenamento de um conjunto organizado de dados utilizados por uma ou vrias aplicaes. Para desempenhar as tarefas a que se prope, um SGBD coloca disposio dos seus usurios diversas funes, cujas principais seriam armazenar os dados de forma organizada e permitir o acesso seletivo e controlado aos dados armazenados. Dentre as outras funes do SGBD temos: garantir a segurana dos dados, isto , garantir que os dados armazenados no banco de dados no sejam perdidos (caso ocorra uma falha que provoque a perda dos dados, o SGBD deve dispor de um modo de restaurar os dados a partir de uma cpia de segurana, o famoso backup dos dados); garantir a integridade dos dados, isto , impedir que sejam inseridos dados incorretos no banco de dados; garantir uma poltica de acesso, isto , garantir que apenas as pessoas devidamente autorizadas tenham acesso aos dados armazenados e, at mesmo, somente tenham acesso ao tipo de dados para o qual tenham sido autorizadas (por exemplo, um determinado usurio pode ter acesso ao valor do total de salrios pagos, mas no pode acessar o salrio de um determinado indivduo); outras funes, normalmente despercebidas pelo usurio, tais como funes de reorganizao para melhorar o desempenho.

Cada SGBD implementa de modo particular a maneira como armazena os dados, controla o acesso aos dados, interage com o usurio do sistema, prov a segurana dos

Banco de Dados

6.68

dados etc. A esse conjunto de programas e modo de implementao damos o nome de arquitetura do sistema de banco de dados. Falamos acima em usurio do banco de dados. Em princpio, um usurio de um sistema de banco de dados qualquer pessoa (ou grupo de pessoas) que interage com o sistema. Dependendo do tipo de interao, podemos classificar os usurios em diversas categorias: Usurio (como so comumente conhecidos) Neste grupo esto todos os que realizam operaes de manipulao de dados armazenados no banco de dados. A esto includos os programadores de aplicaes (que desenvolvem aplicaes que manipulam dados do banco de dados), os usurios sofisticados (que utilizam algum tipo de linguagem de consulta, diferente das linguagens de programao tradicionais, que lhes permitem acessar diretamente o banco de dados), os usurios especializados (que interagem com o banco de dados atravs dos programas desenvolvidos pelos programadores de aplicaes) e os usurios encarregados de inserir e atualizar os dados do banco de dados usando, tambm, programas desenvolvidos pelos programadores de aplicaes (ao contrrio dos usurios sofisticados e dos usurios especializados, que desejam extrair informaes dos dados armazenados no banco de dados). Administrador Neste grupo esto todos os que so responsveis pelo controle do sistema. A esto includos o administrador de dados (que define que dados devem ser armazenados no banco de dados, como estes dados devem se relacionar e define a poltica de acesso aos dados armazenados no banco de dados) e o administrador do SGBD (encarregado de vrias tarefas diretamente ligadas operao do SGBD, tais como a sua instalao, definio da estrutura de armazenamento e da estratgia de acesso aos dados, implementao da poltica de concesso de autorizao de acesso nos mais diversos nveis, definio e implementao de controles de integridade dos dados, definio e implementao de estratgias de segurana dos dados, monitoramento do desempenho do sistema executando, inclusive, alteraes na estrutura fsica do banco de dados e reorganizao dos arquivos para garantir o nvel de funcionamento desejvel). A interao dos usurios com o sistema de banco de dados feita por meio de linguagens especiais, pois, infelizmente, no podemos nos comunicar com o SGBD atravs de uma linguagem natural como o Portugus ou mesmo o Ingls. Estas linguagens se dividem em Linguagem de Definio de Dados (LDD em portugus ou DDL Data Definition Language em ingls) e Linguagem de Manipulao de Dados (LMD em portugus ou DML Data Manipulation Language). Uma LDD utilizada pelo administrador do SGBD para definir os arquivos que comporo o banco de dados e mesmo para promover a reorganizao do banco de dados quando necessrio. Uma LMD utilizada pelos usurios que precisam manipular os dados armazenados no banco de dados. Os programadores de aplicaes embutem os comandos da LMD nos seus programas. Os usurios sofisticados usam diretamente uma LMD. Como vimos, os demais usurios acessam os dados atravs de programas desenvolvidos pelos programadores de aplicaes. Atualmente, a LMD mais utilizada a SQL (Structured Query Language Linguagem de Consulta Estruturada). Hoje em dia, praticamente todos os SGBD seguem o modelo relacional, com algumas poucas tentativas com o modelo de SGBD baseado em objetos. Porm, antes que o modelo relacional predominasse, dois outros modelos eram tambm usados. O Banco de Dados 7.68

modelo hierrquico e o modelo em rede (que no tem nada a ver com rede de computadores). Mais adiante voltaremos a falar nestes modelos. O que interessa agora que na poca em questo, muitas vezes ao se projetar uma aplicao usando banco de dados, no se sabia a priori que tipo de SGBD seria usado. Era preciso, ento, encontrar uma forma de projetar o banco de dados que servisse para qualquer modelo de SGBD. A soluo encontrada foi distanciar a descrio dos dados necessrios para a aplicao dos arquivos usados no SGBD. Criouse ento o conceito de modelos de dados, que so as descries dos dados, e separaram-se os modelos em modelo conceitual, modelo lgico e modelo fsico. O modelo conceitual uma descrio de alto nvel, mais prxima da realidade da aplicao a que se destina o banco de dados. Assim, o modelo criado fica independente do SGBD que ser utilizado. Dentre as diversas alternativas de mtodo para a criao do modelo conceitual, destacou-se o Modelo de Entidade e Relacionamentos (MER) que se tornou muito popular e o mais usado atualmente. Por esse motivo ao tratarmos, mais adiante, de modelagem conceitual de dados falaremos apenas do MER. O modelo lgico consiste na traduo do modelo conceitual de dados criado na primeira fase para um dos modelos de SGBD (hierrquico, em rede ou relacional). Esta etapa era necessria devido grande diferena entre as arquiteturas dos trs modelos de SGBD. O modelo fsico consiste na traduo do modelo lgico para um SGBD especfico. Isso porque havia mais de um fornecedor de SGBD de um mesmo modelo (em rede, por exemplo) e cada um usava uma LDD (Linguagem de Definio de Dados) diferente. Hoje, apesar da predominncia do SGBD relacional, permanece a separao entre os modelos conceitual e lgico e fsico, pois facilita o projeto do banco de dados. A passagem do modelo conceitual para o modelo lgico ficou mais simples, pois temos apenas o modelo relacional, da mesma forma que do modelo lgico para o modelo fsico, devido quase padronizao das LDD.

1.3 Exerccios
1) Defina: sistema de bancos de dados; banco de dados; sistema de gerenciamento de banco de dados. 2) Quais as vantagens e desvantagens da utilizao de um sistema de banco de dados? 3) Defina: linguagem de definio de dados; linguagem de manipulao de dados. 4) Como se classificam os usurios do banco de dados e quais as suas funes? 5) Defina: modelo conceitual de dados; modelo lgico de dados; modelo fsico de dados.

Banco de Dados

8.68

2 Modelo conceitual de dados

Usaremos para a modelagem conceitual de dados o Modelo de Entidade e Relacionamentos. Este modelo foi proposto por Peter Chen em 1976 e, de l para c, recebeu alguns acrscimos e complementaes. Ao nos depararmos com a tarefa de projetar uma nova aplicao ou, mais especificamente, um banco de dados para atender a uma determinada aplicao, devemos estudar o ambiente onde o banco de dados ser usado e as necessidades de informao que se espera suprir com o mesmo. Ao longo do estudo procuramos entender como a aplicao deve funcionar e quais dados sero necessrios para a sua implementao. Vamos supor que no nosso estudo tenhamos determinado que seja necessrio armazenar dados sobre os funcionrios da empresa e que os dados necessrios esto representados no formulrio apresentado a seguir: Dados Cadastrais do Funcionrio Matrcula: Data Nasc.: Est. Civil: Endereo: Data Adm.: Nome: Cargo: Dependentes Data Nasc.: Nome: Nacionalidade: RG: CIC: Telefone: Salrio: Sexo:

Fig. 2.1: Dados cadastrais de um funcionrio. Poderamos ser tentados a criar um nico arquivo para esses dados, com um registro para cada funcionrio (nos primeiros tempos da informtica era mais ou menos assim que era feito). Essa soluo, entretanto, acarreta vrios problemas. No vamos nos aprofundar nesses problemas agora. Vamos citar apenas um para exemplificar: os dados relativos aos dependentes. Se deixarmos espao para trs dependentes, quando aparecer um funcionrio com mais de trs dependentes, o nosso banco ter que ser reestruturado. Se deixarmos espao para dez dependentes, estaremos gastando espao no arquivo, pois, certamente, haver poucos funcionrios com tantos dependentes. Fizemos analogia com um arquivo apenas para facilitar a compreenso do tipo de problemas que foram encontrados pelos primeiros estudiosos da tecnologia de banco de dados e o porqu das solues adotadas. Como estamos querendo criar o modelo conceitual dos nossos dados, no nos preocuparemos (e nem devemos nos deixar influenciar) com a forma como os dados sero armazenados. Na modelagem conceitual queremos apenas entender e descrever os dados necessrios e como esses dados devem ser tratados. Tambm do nosso estudo, conclumos que os funcionrios esto ligados a departamentos e participam de projetos.

Banco de Dados

9.68

Portanto, sabemos por enquanto que precisamos armazenar dados sobre os funcionrios, os departamentos e os projetos. Para ns, o conjunto de todos os funcionrios ser uma entidade no nosso modelo. Da mesma forma, os departamentos e os projetos sero entidades no nosso modelo. Descobrimos, ento, trs entidades que chamaremos de funcionrios, departamentos e projetos. E, o que essas trs entidades tm em comum? Elas representam objetos do mundo real. Ora, mas departamento um objeto? Sim, pois, para nossa anlise consideramos objetos os seres, os fatos, as coisas e os organismos sociais. Assim, um funcionrio (um ser) um objeto, um departamento (um organismo social) um objeto etc. Mesmo se for apenas uma idia que s existe no papel, tal como uma conta-corrente bancria, tambm ser considerada um objeto neste contexto. Podemos, ento, definir uma entidade como uma representao abstrata de um conjunto de objetos (no sentido que definimos acima) do mundo real. A entidade funcionrios representa os funcionrios da empresa (o conjunto dos funcionrios) e dizemos que um funcionrio especfico uma ocorrncia (um exemplar) da entidade funcionrios.

Joo Maria Jos Pedro Antnio Snia

Fig. 2.2: A entidade funcionrios representada como um conjunto. Para representar um objeto, usamos os dados correspondentes a esse objeto. Para a entidade funcionrios, por exemplo, poderamos usar a matrcula, o nome, a data de nascimento etc. A escolha dos dados para cada entidade depende do contexto e da nossa rea de interesse. Aos dados usados para representar os objetos de uma entidade damos o nome de atributos. Assim, temos os atributos matrcula, nome, data de nascimento etc., para a entidade funcionrios. Dissemos acima que os funcionrios esto ligados a departamentos e participam de projetos. No nosso modelo dizemos que h um relacionamento entre as entidades funcionrios e departamentos e outro entre as entidades funcionrios e projetos.
Joo Maria Jos Pedro Antnio Snia funcionrios

funcionrios

Compras Pessoal Financeiro departamentos

Fig. 2.3: Relacionamento entre as entidades funcionrios e departamentos. Banco de Dados 10.68

Criar um modelo conceitual de dados para um banco de dados usando o Modelo de Entidade e Relacionamentos (MER) consiste, ento, em identificar as entidades, seus atributos e relacionamentos. Para representar o modelo conceitual usaremos o Diagrama de Entidades e Relacionamentos (DER). No DER usaremos a seguinte simbologia: as entidades sero representadas por retngulos e os relacionamentos por losangos, como na figura a seguir.
Funcionrios Lotaes Departamentos

Fig. 2.4: Exemplo de um Diagrama de Entidades e Relacionamentos. Com essa figura queremos representar que existe um relacionamento entre a entidade funcionrios e a entidade departamentos. Os nomes no interior das figuras indicam que os funcionrios esto lotados nos departamentos. Normalmente omitimos do DER os atributos. Caso haja necessidade de represent-los, usaremos a seguinte simbologia:

Funcionrios
Data Nascimento Nome Matrcula
Fig. 2.5: A entidade funcionrios representada com alguns atributos. importante notar que podemos ter mais de um relacionamento entre duas entidades quaisquer. Podemos, por exemplo, ter os seguintes relacionamentos entre as entidades funcionrios e departamentos:
Funcionrios Lotaes Departamentos

Gerencia

Fig. 2.6: Dois relacionamentos entre as entidades funcionrios e departamentos.

2.1 Cardinalidade dos relacionamentos

Na figura 2.2, onde mostramos o relacionamento lotaes entre os funcionrios e os departamentos, est indicado qual funcionrio est ligado a qual departamento, isto , que os funcionrios Joo, Jos e Snia esto ligados ao departamento Compras. Mas, na realidade, esse detalhe no nos interessa. Para efeito de modelagem interessa saber que funcionrios esto relacionados com departamentos, ou seja, que a entidade funcionrios se relaciona com a entidade departamentos atravs do relacionamento lotaes. Um fato importante, do ponto de vista da modelagem, a forma como se d este relacionamento. Ser que todo elemento de uma entidade participa do relacionamento ou podem ocorrer situaes em que isso no seja verdade? Um elemento de uma entidade pode se relacionar com mais de um elemento da outra entidade? Banco de Dados 11.68

A resposta : depende. No caso do relacionamento entre funcionrios e departamentos, normalmente todo funcionrio est lotado em algum departamento, apesar de que, podemos ter alguma empresa em que determinados funcionrios, assessores da presidncia, por exemplo, no estaro vinculados a nenhum departamento (no adequado criar um departamento fictcio para acomodar essa situao). Portanto, depende do contexto que estivermos analisando. Se analisarmos o relacionamento do ponto de vista da entidade departamentos, veremos que um departamento est relacionado com vrios funcionrios (h vrios funcionrios lotados em cada departamento). quantidade de elementos de cada entidade que pode participar de um relacionamento damos o nome de cardinalidade do relacionamento e representamos por meio de nmeros no diagrama, como mostrado a seguir:

Funcionrios

Lotaes

Departamentos

Fig. 2.7: Representao da cardinalidade entre relacionamentos. No diagrama acima estamos representando que, atravs do relacionamento Lotaes, vrios elementos da entidade Funcionrios podem estar ligados a um elemento da entidade Departamentos. No sentido inverso, um departamento pode estar ligado a vrios funcionrios. Note-se que no estamos interessados em saber exatamente quantos funcionrios esto ligados a cada departamento, pois esse nmero pode variar de um departamento para outro. Assim, dizemos que o relacionamento da ordem de 1:N (de 1 para N) no sentido Departamentos para Funcionrios (um departamento pode estar relacionado a vrios funcionrios) e de N:1 no sentido Funcionrios para Departamentos. Como veremos adiante, em certas situaes interessante indicar um limite mnimo e um limite mximo. Apenas para exemplificar, consideremos o relacionamento entre os alunos e as turmas de uma escola. Neste caso pode ser necessrio indicar um limite mximo para o nmero de alunos em cada turma. No normal um funcionrio estar lotado em mais de um departamento ao mesmo tempo. Entretanto, se considerarmos o relacionamento entre os funcionrios e os projetos, no incomum o fato de um funcionrio participar de mais de um projeto. Neste caso dizemos que o relacionamento de N:N:

Funcionrios

Participaes

Projetos

Fig. 2.8: Relacionamento de N:N. Para determinar a cardinalidade de um relacionamento, examinamos primeiro em uma direo. No relacionamento Lotaes, por exemplo, deveramos nos perguntar: um funcionrio se relaciona com um ou mais departamentos? Como cada funcionrio est lotado em apenas um departamento, o relacionamento de Funcionrios com Departamentos ser de 1:1. No sentido inverso, a pergunta seria: um departamento se relaciona com um ou mais funcionrios? Como teremos vrios funcionrios lotados em cada departamento, o relacionamento de Departamentos com Funcionrios ser de 1:N.

Banco de Dados

12.68

Invertendo, para efetuar a leitura sempre da esquerda para a direita, teremos a cardinalidade 1:1 em um sentido (cada funcionrio alocado a um nico departamento) e N:1 no outro sentido (cada departamento com vrios funcionrios). Tomamos, ento, os maiores valores e ficaremos com a cardinalidade N:1 para o relacionamento Alocaes entre as entidades Funcionrios e Departamentos. Poderamos representar graficamente essa situao com a seguinte figura para o relacionamento Locaes: Funcionrio Um funcionrio 1 Muitos funcionrios N N Departamento Um departamento 1 Um departamento 1 N

Fig. 2.9: Determinando a cardinalidade de um relacionamento. Na literatura sobre bancos de dados h vrias nomenclaturas para a cardinalidade (formas de representar a cardinalidade) no DER. Utilizamos essa por acharmos mais simples e intuitiva. Voltando s entidades Funcionrios e Departamentos, temos um outro relacionamento: o que indica que um determinado funcionrio o gerente do departamento. Podemos representar esse relacionamento da seguinte forma:

Funcionrios

Gerencia

Departamentos

Fig. 2.10: Relacionamento: funcionrio gerencia departamento. Neste caso dizemos que o relacionamento da ordem 1:1 (a cardinalidade do relacionamento 1:1), pois um funcionrio gerente de um departamento apenas e cada departamento tem apenas um gerente. Em certas situaes interessante indicar os limites para o relacionamento. Por exemplo, podemos querer indicar que um departamento pode ter vrios funcionrios, mas no pode haver nenhum departamento sem funcionrio. Nestes casos indicaremos entre parnteses os limites mnimo e mximo da cardinalidade:
(1,N) Funcionrios Lotaes 1 Departamentos

Fig. 2.11: Limitando a cardinalidade. Considerando que no relacionamento gerencia entre as entidades funcionrios e departamentos todo departamento tem um e apenas um gerente, e nem todos os funcionrios so gerentes, a melhor representao seria:
1 Funcionrios Gerencia (0,1) Departamentos

Fig. 2.12: Limitando a cardinalidade.

Banco de Dados

13.68

Se quisermos indicar que cada departamento deve ter no mnimo um funcionrio, mas que podemos ter funcionrios que no esto lotados em nenhum departamento usaramos:

(1,N) Funcionrios Lotaes

Fig. 2.13: Limitando a cardinalidade.

(0,1) Departamentos

2.2 Auto-relacionamento
No exemplo anterior consideramos o fato de um funcionrio gerenciar um departamento. Essa situao representada no nosso modelo atravs do relacionamento Gerencia entre as entidades Funcionrios e Departamentos. Uma outra situao ocorre quando queremos indicar que um funcionrio o gerente de outros funcionrios. Neste caso teremos um relacionamento entre um funcionrio e outros funcionrios, isto , um relacionamento entre a entidade Funcionrios e ela prpria. A este tipo de relacionamento chamamos auto-relacionamento e representamos:
Gerenciamento de pessoal Gerencia gerenciado

1 Funcionrios

Fig. 2.14: Auto-relacionamento. Neste caso, um funcionrio gerencia vrios outros (relacionamento 1:N) e vrios funcionrios so gerenciados por um funcionrio (relacionamento N:1). Nos outros relacionamentos (funcionrio gerencia departamento, por exemplo) o tipo do relacionamento era evidente, o que no ocorre no auto-relacionamento. Para evitar ambigidade, o papel exercido pelas ocorrncias no relacionamento (Gerencia/ Gerenciado) indicado no diagrama no caso do auto-relacionamento. Outro exemplo de auto-relacionamento a situao em que queremos representar o fato de uma pea produzida por uma empresa ser constituda de outras peas.

2.3 Atributos
Como j dissemos, os atributos so os dados usados para representar os objetos de uma entidade. Assim, na entidade Funcionrios poderamos ter os atributos matrcula, nome e data do nascimento:
Funcionrios
Data Nascimento Nome Matrcula

Fig. 2.15: A entidade funcionrios representada com alguns atributos. Banco de Dados 14.68

Se examinarmos o formulrio Dados Cadastrais do Funcionrio (repetido a seguir) que obtivemos ao estudar o ambiente da nossa aplicao de banco de dados, notaremos que os atributos correspondem, de certa forma, aos campos do formulrio. Dados Cadastrais do Funcionrio Matrcula: Data Nasc.: Est. Civil: Endereo: Data Adm.: Nome: Cargo: Dependentes Data Nasc.: Nome: Nacionalidade: RG: CIC: Telefone: Salrio: Sexo:

Fig. 2.16: Dados cadastrais de um funcionrio. Alm desses trs atributos, podemos ter outros, como vemos no formulrio. A escolha dos atributos que vamos incluir no nosso modelo vai depender das necessidades da nossa aplicao. O interessante a observar aqui que os atributos podem possuir caractersticas diferentes. O atributo nome possui um nico valor para cada objeto da nossa entidade. A um atributo deste tipo classificamos como atributo mono-valorado. J um atributo como endereo, que formado por outros sub-atributos, classificamos como atributo composto. Um atributo multivalorado aquele que possui diversos valores para o mesmo objeto como, por exemplo, o atributo nome do dependente, que possui um valor para cada dependente. Um atributo determinante o que possui um valor distinto para cada objeto da entidade e, portanto, identifica de maneira inequvoca o objeto. Ao conjunto de valores que um atributo pode assumir chamamos domnio do atributo. O atributo sexo, por exemplo, ter como domnio o conjunto {M,F} (quem se sentir excludo poder acrescentar outros valores ao conjunto ao efetuar a sua modelagem).

2.3.1 Atributos do relacionamento

Consideremos que queremos modelar o relacionamento entre a entidade fornecedores e a entidade produtos:

Fornecedores

Fornece

Produtos

Fig. 2.17: Relacionamento entre fornecedores e produtos. Banco de Dados 15.68

A cardinalidade do relacionamento , sem sombra de dvida, da ordem N:N (um fornecedor pode fornecer vrios produtos e um mesmo produto pode ser fornecido por vrios fornecedores). Examinemos agora os atributos (apenas os essenciais para o nosso exemplo). Na entidade fornecedores poderamos ter: Cdigo do fornecedor e Nome do fornecedor. Na entidade produtos teramos: Cdigo do produto e Descrio do produto. E se quisermos representar a quantidade, e tambm o preo, de um determinado produto fornecido por um dos fornecedores? Esses atributos estariam vinculados a qual entidade: fornecedores ou produtos? Na realidade a nenhuma das duas entidades, pois eles so atributos do relacionamento fornece.

Fornecedores

Fornece

Produtos
Descrio do produto Cdigo do produto

Nome do fornecedor Cdigo do fornecedor

Preo do produto Quantidade fornecida

Fig. 2.18: Atributos do relacionamento. O problema que surge : como determinar se um atributo est associado a uma entidade ou a outra entidade do relacionamento ou se um atributo do relacionamento? Existe um mtodo prtico para nos auxiliar nesta tarefa. No exemplo acima no h dvida quanto aos atributos cdigo do fornecedor, nome do fornecedor, cdigo do produto e descrio do produto. Examinemos, ento, os atributos quantidade fornecida e preo do produto. Como um fornecedor pode fornecer vrios produtos, fixamos um fornecedor e fazemos variar o produto. Se mudarmos de fornecedor a quantidade fornecida (ou o preo) permanece fixa ou sofre alterao? Se permanecer fixa o atributo da entidade fornecedores, caso contrrio, no . No presente caso, os atributos quantidade fornecida e preo do produto no permanecem fixos, portanto, no so atributos da entidade fornecedores. Em seguida, invertemos o teste. Fixamos um produto e fazemos variar o fornecedor. Novamente, se o atributo em questo (quantidade fornecida e preo do produto) no sofrer alterao, ento um atributo da entidade produtos. Caso contrrio, no . De novo, no presente caso, os atributos quantidade fornecida e preo do produto sofrem alterao. Portanto, no so atributos da entidade produtos. Como quantidade fornecida e preo do produto no so atributos da entidade fornecedores e nem da entidade produtos so, ento, atributos do relacionamento fornece, existente entre as entidades fornecedores e produtos.

2.4 Agregao
Consideremos a situao de uma escola onde cada professor pode lecionar vrias disciplinas e cada aluno pode estar matriculado em vrias disciplinas. Em princpio, teramos um relacionamento triplo:
Alunos A-D-P Disciplinas

Professores

Fig. 2.19: Relacionamento entre 3 entidades. Banco de Dados 16.68

Examinando melhor o exemplo, vemos que um professor leciona para vrios alunos uma determinada disciplina. Ou seja, para uma determinada disciplina os alunos tm um nico professor. Por outro lado, um determinado grupo de alunos pode ter aulas com um mesmo professor, porm em disciplinas diferentes. Portanto, o professor no se relaciona diretamente com alunos e com disciplinas e sim com o relacionamento entre alunos X disciplinas. A representao das entidades sob forma de conjuntos mostrando as ocorrncias de cada um nos ajuda a entender melhor a situao:
a1 a2 a3 a4 a5 a6 alunos d1 d2 d3 d4 disciplinas

P1

P2

P3

P4

Fig. 2.20: Relacionamento entre 3 entidades representado como conjuntos. Observando a figura acima podemos notar que alguns alunos no participam de nenhum relacionamento (A3 e A5), assim como algumas disciplinas (D3) e alguns professores (P3). Entretanto, sempre que temos um relacionamento ele envolve simultaneamente uma ocorrncia de cada entidade. Entretanto, o Modelo de Entidades e Relacionamentos no permite o relacionamento entre relacionamentos. Para contornar essa restrio, lanamos mo da agregao. A agregao uma abstrao atravs da qual relacionamentos so tratados como entidades de nvel superior.
Alunos N Cursa N Disciplinas

professores

N Leciona 1 Professores

Fig. 2.21: Exemplo de agregao. Neste diagrama mostramos que a entidade professores se relaciona com o relacionamento cursa existente entre as entidades alunos e disciplinas. As cardinalidades esto representadas na figura. Um aluno pode cursar vrias disciplinas e uma disciplina pode ter vrios alunos (cardinalidade N:N). Um professor pode lecionar vrias disciplinas para vrios grupos de alunos (aqui devemos considerar o par: Banco de Dados 17.68

disciplina X grupo de alunos) e cada grupo de alunos matriculado em uma disciplina tem apenas um professor (cardinalidade 1:N).

2.4.1 Restries para o uso da agregao

Uma vez que temos trs entidades se relacionando, podemos nos perguntar: Ser que podemos considerar qualquer uma das entidades se relacionando com o relacionamento entre as outras duas? Ou seja, no exemplo acima, ser que podemos trocar de posio as entidades alunos e professores? A resposta no, pois o relacionamento entre professores e disciplinas da ordem 1:N (um professor pode lecionar vrias disciplinas mas, cada disciplina pode ter apenas um professor). Neste caso teramos que representar o relacionamento entre professores e disciplinas e outro relacionamento entre disciplinas e alunos:
Alunos Cursa Disciplinas

Leciona

Professores

Fig. 2.22: Este exemplo no forma agregao. Entretanto, essa representao no mostra o relacionamento entre professores e alunos.

2.5 Generalizao e Especializao

H situaes em que os atributos de uma entidade no so os mesmos para todas as ocorrncias da entidade, isto , no se aplicam a todas as ocorrncias. Por exemplo, em uma entidade clientes podemos ter o atributo cpf, se o cliente for do tipo pessoa fsica, e o atributo cgc, se for do tipo pessoa jurdica. H tambm situaes em que h um relacionamento entre entidades, mas nem todas as ocorrncias da entidade participam do relacionamento (e jamais viro a participar). Por exemplo, em uma entidade funcionrios nem todos os funcionrios (ocorrncias) participaro do relacionamento com uma entidade projetos (os funcionrios engenheiros participaro, enquanto que os funcionrios motoristas no). Note-se que esta situao diferente do relacionamento entre a entidade professores e disciplinas visto anteriormente, em que um professor podia no estar temporariamente relacionado com nenhuma disciplina.

Banco de Dados

18.68

Estas situaes podem ser modeladas por meio do recurso de especializao (tambm chamado de particionamento de conjunto):
Clientes
Nome Endereo

Classif. fiscal

CPF

Pessoas fsicas

Pessoas jurdicas

CGC

Fig. 2.23: Exemplo de especializao. Estamos representando neste exemplo que a entidade clientes possui os atributos nome e endereo e que particionada em dois conjuntos: pessoas fsicas e pessoas jurdicas. O conjunto pessoas fsicas possui o atributo cpf e o conjunto pessoas jurdicas possui o atributo cgc. No sentido a partir do conjunto clientes para os conjuntos pessoas fsicas e pessoas jurdicas dizemos que ocorre uma especializao. No sentido inverso, generalizao. Quando as ocorrncias da entidade particionada (clientes, no presente caso) se dividem completamente nos diversos sub-conjuntos, dizemos que ocorre uma especializao total. o que acontece neste exemplo. Os clientes so pessoas fsicas ou so pessoas jurdicas. Ningum fica de fora. Veremos a seguir um exemplo em que apenas algumas ocorrncias da entidade participam de um relacionamento. Este exemplo (figura 2.24) servir, tambm, para mostrar um caso de especializao parcial. Neste exemplo estamos representando que apenas os engenheiros participam do relacionamento com a entidade projetos. Como, seguramente, h na entidade funcionrios alguns funcionrios que no so motoristas e nem engenheiros, est configurado um caso de especializao parcial.
Funcionrios

Categoria funcional

Motoristas

Engenheiros

Nmero da CNH

Participa

Projetos

Fig. 2.24: Exemplo de especializao parcial. Banco de Dados 19.68

2.6 Dicas para a Relacionamentos

criao

do

Diagrama

de

Entidades

Dissemos no incio do tpico Modelo conceitual de dados que devemos estudar o ambiente onde o banco de dados ser usado e as necessidades de informao que se espera suprir com o mesmo. Basicamente o que procuramos identificar so as entidades e os relacionamentos entre elas. Examinando o texto que produzimos para descrever o ambiente que encontramos, podemos usar as seguintes dicas para ajudar a identificar os componentes do nosso modelo: a) a presena de um substantivo geralmente indica uma entidade: os engenheiros participam de projetos; b) a presena de um verbo uma forte indicao de um relacionamento: os engenheiros participam de projetos.

2.7 Exerccios
1) Construa um DER (Diagrama de Entidades e Relacionamentos) para um hospital com um conjunto de pacientes e um conjunto de mdicos. A cada paciente so associados os registros de diversos exames. 2) Construa um DER para uma companhia de seguros de automveis com um conjunto de clientes, onde cada um possui um certo nmero de carros. Cada carro tem um nmero de acidentes associados a ele. 3) Desenhe um exemplo para cada um dos relacionamentos apresentados a seguir, mostrando as ocorrncias em cada um deles:
a) 1 Gerenciamento de pessoal N

Gerencia

gerenciado

Funcionrios

b) N Compe N

Composta

Componente

Peas

4) O diagrama a seguir mostra o relacionamento entre trs entidades. Como o Modelo de Entidades e Relacionamentos no permite este tipo de relacionamento, refaa-o e desenhe o DER correspondente.

Banco de Dados

20.68

Cidades

C-D-P

Distribuidores

Produtos

5) Explique a diferena entre uma entidade (conjunto-entidade) e uma ocorrncia (instncia) de uma entidade. 6) O que o papel de uma entidade em um relacionamento? Quando necessrio especific-lo? 7) Considere que em uma empresa um dependente de um empregado possa ser tambm um empregado. Como voc modelaria essa situao? 8) Complete o diagrama abaixo para especificar o seguinte:

Tem como pr-requisito

Pr-requisito pr-requisito Disciplinas

Departamentos

Controla

Compe

Alunos

Cursa

Cursos

a) Um curso no pode estar vazio, isto , deve possuir alguma disciplina em seu currculo; b) Um aluno, mesmo que no inscrito em nenhum curso, deve permanecer por algum tempo no banco de dados; c) Um aluno pode fazer mais de um curso.

3 Estudo de caso (parte 1)

Para termos uma viso mais prtica do que estamos estudando, vamos apresentar uma empresa hipottica que ser usada ao longo deste trabalho. Ao final de cada etapa usaremos essa empresa para exercitar o que acabou de ser visto, at que, ao final, teremos uma aplicao usando banco de dados implementada. O ambiente que escolhemos uma empresa atacadista, pois permite elaborar uma aplicao de complexidade mdia e d margem a futuras ampliaes.

Banco de Dados

21.68

O ponto de partida ser o relatrio que descreve a empresa que se pretende informatizar, produzido pela equipe de analistas aps uma srie de entrevistas com os gerentes e outros funcionrios da empresa. O processo de obteno dessas informaes foge do escopo deste trabalho e, portanto, no ser abordado.

3.1 Relatrio da anlise

A empresa Atacado do Dinho (AdD) uma empresa do ramo de vendas de produtos descartveis por atacado, que atua em diversos estados vizinhos sua sede. A empresa compra produtos de vrios fornecedores, indstrias que produzem artigos descartveis para bares, restaurantes, hotis e hospitais. As vendas so efetuadas por meio da equipe de vendedores, sempre para clientes cadastrados. As mercadorias vendidas podem ser entregues aos compradores no balco da AdD ou diretamente no endereo indicado pelo cliente, por meio da frota prpria de caminhes. Os gerentes da AdD querem que o sistema controle trs grupos de funcionrios da empresa: os vendedores, os motoristas e o pessoal do almoxarifado. Uma vez por ms dever ser emitido um relatrio das vendas, com o clculo das comisses dos vendedores (um percentual sobre o total das vendas do ms). Os motoristas recebem uma bonificao (valor fixo) por entregas sem acidentes durante o ms. Os funcionrios responsveis pelo almoxarifado tm vrias atribuies. So encarregados de controlar o estoque, verificando os produtos que esto com a quantidade abaixo do nvel de reposio. Para os produtos que necessitam de reposio eles emitem um pedido de compra para os fornecedores, escolhendo sempre aqueles com o menor preo de venda para cada produto. So tambm encarregados de controlar o recebimento das mercadorias, atualizando o estoque. Ao efetuar uma compra os clientes podem optar pelo pagamento vista ou com prazo de 30 dias. Para cada venda dever ser emitida uma nota fiscal.

3.2 Estudo de caso modelo conceitual de dados

Para criar o modelo conceitual de dados usando o Modelo de Entidades e Relacionamentos, devemos procurar descobrir as entidades que descrevem o nosso objeto de estudo, o relacionamento entre as entidades e os atributos das entidades e dos relacionamentos. Vamos relembrar aqui as dicas para a criao do DER: a) a presena de um substantivo geralmente indica uma entidade; b) a presena de um verbo uma forte indicao de um relacionamento. Devemos examinar o relatrio da anlise, produzido pela equipe de analistas, procurando identificar as entidades, os relacionamentos e os atributos. Tomemos a frase A empresa compra produtos de vrios fornecedores, indstrias que produzem artigos descartveis para bares, restaurantes, hotis e hospitais, contida no relatrio. Esta frase contm vrios substantivos, verbos etc. Entretanto, no podemos simplesmente criar uma entidade para cada substantivo encontrado. Devemos lembrar que a presena de um substantivo geralmente indica uma entidade. Portanto, a dica apenas uma sugesto e no uma regra. Banco de Dados 22.68

Devemos examinar melhor a frase e extrair dela as informaes fundamentais, que podem ser resumidas na frase: fornecedores fornecem produtos. Os substantivos fornecedores e produtos podem ser entidades e o verbo fornecem pode ser um relacionamento. Fornecedores e produtos so entidades do mundo real. Mas, como ter certeza de que devem ser includas no nosso modelo? muito simples. Basta verificarmos se precisamos guardar no nosso sistema dados sobre estas entidades. Seguramente precisaremos guardar dados sobre os fornecedores: entre outros, seu nome e endereo. E tambm sobre os produtos: sua descrio, unidade de medida etc. Podemos ver que h um relacionamento entre os fornecedores e os produtos: o fato daqueles fornecerem produtos. Sobre esse relacionamento precisamos de, pelo menos, um dado: o preo do produto fornecido por cada fornecedor. Portanto, conclumos que fornecedores e produtos so entidades que devem constar do DER e tambm o relacionamento fornece entre essas entidades.

Fornecedores

Fornece

Produtos

Fig. 3.1: Incio do DER para o estudo de caso. As cardinalidades do relacionamento esto indicadas no diagrama: um fornecedor pode fornecer vrios produtos e um produto pode ter mais de um fornecedor. Os atributos foram omitidos e s sero representados quando se fizerem necessrios. Nem sempre acertamos de primeira. No decorrer da criao do DER vamos sentindo a necessidade de acrescentar outras entidades e relacionamentos e, at mesmo, excluir algumas entidades e alterar outros relacionamentos. Isso normal no processo. Examinando novamente o relatrio da anlise construmos a seguinte lista de provveis entidades (voc provavelmente construiria uma lista um pouco diferente): clientes (pessoas ou empresas que compram na AdD) vendedores (funcionrios da AdD que efetuam vendas para os clientes) almoxarifes (funcionrios da AdD que controlam o estoque) motoristas (funcionrios da AdD que efetuam as entregas dos produtos comprados pelos clientes)venda (relao de produtos vendidos por um vendedor a um cliente) entrega (relao de produtos entregues aos clientes por um motorista) fornecedores (empresas que vendem produtos para a AdD) produtos (mercadorias compradas dos fornecedores e vendidas para os clientes) estoque (relao de produtos comprados aos fornecedores e disponveis para venda aos clientes) pedido de compra (relao de produtos encomendados a um fornecedor) pagamento (?) nota fiscal (relao de produtos vendidos a um cliente) Todos os itens que constam da relao so entidades do mundo real (muito embora alguma possa ser uma entidade abstrata). Devemos examinar cada uma delas para decidir se devem ser includas no nosso modelo. Uma primeira observao: note-se que difcil descrever a entidade candidata pagamento. Essa dificuldade uma forte indicao de que, provavelmente, ela no uma entidade.

Banco de Dados

23.68

Examinando as demais entidades candidatas, conclumos que algumas so fortes candidatas: clientes, vendedores, almoxarifes, motoristas, fornecedores e produtos. Precisamos guardar dados para cada uma delas: nome, endereo, CPF ou CGC etc. para clientes nome e cargo para vendedores nome e cargo para almoxarifes nome e cargo para motoristas nome, endereo, CGC etc. para fornecedores descrio, unidade de medida etc. para produtos. Para as demais precisamos efetuar uma anlise mais detalhada. Vrios questionamentos devem ser feitos at se chegar a uma concluso e a enumerao de todos eles tornaria esse trabalho muito extenso. Portanto, procuraremos relacionar os que julgamos mais importantes ou interessantes. fcil notar pela prpria descrio que fizemos das entidades candidatas que vendedores, almoxarifes e motoristas compem uma nica entidade, que chamaremos funcionrios. Caso seja necessrio, podemos usar o recurso da especializao para particion-la em duas ou mais entidades. Outra dvida que surge : produtos e estoque so duas entidades diferentes ou no? Inicialmente consideraremos como entidades distintas. Ao detalhar cada uma delas (seus atributos) e os relacionamentos com as outras entidades do modelo teremos mais subsdios para decidir. Observando as descries das entidades candidatas venda (relao de produtos vendidos por um vendedor a um cliente) e nota fiscal (relao de produtos vendidos a um cliente), ficamos com a impresso de que, provavelmente, elas constituem uma nica entidade. Deixaremos a deciso para depois do detalhamento. Outro problema que encontramos se deve ambigidade intrnseca da linguagem natural (portugus, no caso) usada no relatrio da anlise. O mesmo fato (a venda de um produto a um cliente) referido de vrias maneiras: o vendedor vende um produto para um cliente; o cliente compra um produto da empresa etc. Isso pode indicar relacionamentos diferentes entre entidades, mas nem sempre verdade. Por enquanto j avanamos bastante com relao s entidades. Vamos agora tentar definir os relacionamentos, mas, antes vamos fazer um resumo: Clientes Fornecedores Funcionrios Produtos

Fig. 3.2: Entidades identificadas. Vamos rever o relacionamento fornecem, existente entre as entidades fornecedores e produtos. Nossa equipe de anlise voltou a buscar informaes na empresa AdD e concluiu que a empresa recebe as cotaes dos produtos enviadas pelos fornecedores e, quando precisa envia para os fornecedores pedidos de compra de produtos especficos. Como mais de um fornecedor pode oferecer um mesmo produto, o pessoal responsvel pelas compras (os almoxarifes) seleciona o fornecedor usando como critrio o menor preo.

Banco de Dados

24.68

Assim, estabelecemos o relacionamento oferecem, entre fornecedores e produtos:

Fornecedores N Oferecem N Produtos

Fig. 3.3: Relacionamento entre fornecedores e produtos. Ao falarmos em entidades e em relacionamentos esto implcitos os atributos, isto , os dados que queremos guardar no banco de dados para cada um deles. A entidade fornecedores deve ter os seguintes atributos (pode ser necessrio acrescentar outros atributos posteriormente): a identificao do fornecedor e o seu nome. A entidade produtos deve ter os seguintes atributos: a identificao do produto, a descrio do produto e a unidade de medida do produto. O relacionamento oferecem deve ter como atributo o preo oferecido para o produto. Descobrimos, tambm, uma nova entidade, pedidos_compra_fornecedores, que se relaciona com a entidade fornecedores (relacionamento recebem) e com a entidade produtos. O relacionamento recebem direto:
Fornecedores 1 Recebem N Pedidos_compra_ fornecedor

Fig. 3.4: Relacionamento entre fornecedores e pedidos_compra_fornecedor. O relacionamento recebem, entre as entidades fornecedores e pedidos_compra_fornecedores no tem atributos prprios. Para esse relacionamento no precisamos acrescentar nenhum atributo entidade fornecedores. A entidade pedidos_compra_fornecedor ter os seguintes atributos: a identificao do pedido de compra, a identificao do fornecedor, a data de entrega dos produtos que constam do pedido e um cdigo para indicar a situao do pedido. J a entidade pedidos_compra_fornecedor est relacionada entidade produtos:
Pedidos compra fornecedor

Contm

Produtos

Fig. 3.5: Relacionamento entre pedidos_compra_fornecedor e produtos. No h necessidade de novos atributos nas entidades produtos e pedidos_compra_fornecedor devido a esse relacionamento. Mas o relacionamento contm precisa dos atributos preo do produto e a quantidade pedida.

Banco de Dados

25.68

Juntando o que j conseguimos at agora, teramos:

Fornecedores N

Recebem

Pedidos compra fornecedor

Contm

N Oferecem
Fig. 3.6: DER parcial.

N
Produtos

A compra efetuada pelos clientes pode ser modelada da seguinte forma:

Clientes

Fazem

N Pedidos compra N
clientes

Tiram

Vendedores

N
Contm

N
Produtos

Fig. 3.7: Modelagem da compra efetuada pelos clientes. Essa parte do DER deveria ser juntada s anteriores. Deixaremos de faz-lo aqui por dificuldades grficas. Quando estamos criando o DER para sistemas grandes geralmente usamos um software especfico que, entre outros recursos, facilitam a apresentao do resultado. N Neste ponto, devemos nos perguntar: e a nota fiscal? Normalmente a nota fiscal seria modelada de modo muito parecido com o pedido de compra do cliente e, praticamente, com os mesmos atributos. Portanto, os dados do pedido de compra do cliente seriam suficientes. Entretanto, se considerarmos que a nota fiscal deve usar um formulrio pr-impresso (por causa do nmero da nota fiscal) pode acontecer de um determinado pedido de compra ter mais itens do que seria possvel imprimir em uma nica folha do formulrio. Desta forma, um nico pedido de compra pode gerar mais de uma nota fiscal. Logo, precisaremos da entidade notas_fiscal: Fig. 3.8: Modelagem das notas fiscais.
Pedidos compra clientes

Geram

Notas fiscais

Contm

N
Produtos

Banco de Dados

26.68

Neste ponto devemos fazer uma observao: certos relacionamentos, muito embora entre entidades diferentes, so bastante semelhantes (como no caso dos relacionamentos entre pedidos_compra_cliente e produtos e entre notas_fiscais e produtos), de tal modo que se torna difcil encontrar nomes distintos para os relacionamentos. Embora devamos tentar sempre escolher nomes diferentes para os relacionamentos, isto no imprescindvel, a menos que o relacionamento tenha atributos prprios, pois, neste caso, no nvel fsico o relacionamento ser traduzido em uma tabela, que no pode ter nome igual ao de outro objeto do banco de dados. Por esse motivo deixamos os dois relacionamentos acima com o mesmo nome. Um problema que ficou pendente nesta discusso diz respeito s entidades produtos e estoque. Vamos nos aprofundar nesta questo examinando os atributos de cada uma das entidades. A entidade produtos tem, at agora, os seguintes atributos: a identificao do produto, a descrio do produto e a unidade de medida do produto. Para a entidade estoque, os atributos seriam: a identificao do produto, a descrio do produto, a unidade de medida do produto, a quantidade em estoque e o preo de venda do produto. Portanto, podemos concluir que as entidades se superpem, logo devem ser modeladas como uma nica entidade, acrescentando os atributos quantidade em estoque e o preo de venda do produto. Pode ser que, durante a criao do modelo fsico de dados, quando sero definidas as tabelas que comporo o banco de dados, seja interessante separar esta entidade em duas tabelas, para melhorar o desempenho do sistema. Entretanto, no nvel conceitual modelaremos a situao apenas com a entidade produtos. Cremos que o que foi feito at agora neste estudo de caso suficiente para ilustrar o que foi visto na parte terica. Para no nos alongarmos mais no assunto, deixamos a ttulo de exerccio para o leitor complementar o modelo.

4 Modelos lgicos de dados

O Captulo 2 deste trabalho tratou do modelo conceitual de dados. Neste tpico veremos o modelo lgico. Como j citado, hoje em dia, praticamente todos os SGBD seguem o modelo relacional. Houve um tempo, entretanto, em que o modelo relacional conviveu com outros dois modelos: o modelo hierrquico e o modelo em rede. Veremos agora como so esses modelos de dados e assim compreender a evoluo, desde o pioneiro IBMIMS (modelo hierrquico) at o modelo relacional atual. Para cada um dos modelos de dados, mostraremos as suas caractersticas e os motivos da sua criao e porque o modelo foi abandonado.

4.1 Modelo hierrquico

O modelo hierrquico foi o primeiro a ser usado (na poca ainda nem se falava em modelos de dados) e foi fortemente influenciado pelas restries tecnolgicas existentes. No modelo hierrquico os dados so agrupados em registros (como se fossem fichas em um fichrio manual), cada registro contendo os dados sobre um determinado assunto e cada indivduo (cada objeto de interesse do banco de dados) representado por um conjunto de registros. Os registros de cada indivduo so organizados no arquivo formando uma hierarquia com um registro principal (registro pai) e vrios registros secundrios dependentes do registro principal (registros filhos). Banco de Dados 27.68

Em um banco de dados criado para dar suporte a uma aplicao de folha de pagamento, por exemplo, o objeto do banco de dados seria o funcionrio. Teramos no registro pai os dados do funcionrio: Nome Departamento Cargo Salrio ... Fig. 4.1: Registro pai (funcionrio) em um banco de dados hierrquico. Na figura acima colocamos os nomes dos campos para facilitar a compreenso. No arquivo do banco de dados cada campo teria o contedo correspondente: o nome do funcionrio, o departamento onde trabalha, o cargo que ocupa, seu salrio etc. Para a elaborao da folha de pagamento seriam necessrios outros dados. Por exemplo, dados sobre os dependentes do funcionrio. Teramos, ento, um registro para cada dependente: Nome dependente Data Nasc. Grau dep. ... Fig. 4.2: Registro filho (dependente) em um banco de dados hierrquico. Os registros relativos a um funcionrio ficariam organizados da seguinte forma: Jos Jos Jr. Compras 06/12/1990 Auxiliar Filho ... 700,00 ...

Maria Jos 06/12/1991 Filha ... Fig. 4.3: Organizao dos registros no modelo hierrquico. Se precisssemos guardar dados sobre a qualificao do funcionrio, criaramos um grupo de registros para esses dados: Curso Durao ... Fig. 4.4: Registro para a qualificao do funcionario.

Banco de Dados

28.68

e o arquivo ficaria com o seguinte aspecto (no estranhem... naquele tempo no se digitava, datilografava-se): Jos Jos Jr. Datilografia Compras 06/12/1990 6 Auxiliar Filho Filha ... ... ... 700,00 ...

Maria Jos 06/12/1991

... ... ... Fig. 4.5: Exemplo de arquivo em um banco de dados hierrquico. Este modelo de dados tinha uma grande vantagem (foi o pioneiro) e vrias desvantagens. Para alterar o salrio dos auxiliares do departamento de compras era preciso alterar o registro de cada funcionrio lotado no departamento Compras e cujo cargo fosse Auxiliar. Para contornar esse problema, criava-se um arquivo auxiliar contendo a relao de cargos com os respectivos salrios e o salrio do funcionrio era retirado do registro pai. Isso, entretanto, era apenas um paliativo e esse no era o principal problema do modelo hierrquico. O principal problema do modelo hierrquico era sua caracterstica fundamentalmente seqencial. Por exemplo, para emitir um relatrio contendo os nomes de todos os funcionrios com curso de datilografia, o programa tinha que ler primeiro o registro pai e, atravs dele, chegar aos registros de cursos do funcionrio. Outra conseqncia da estrutura hierrquica que o banco era organizado para atender melhor aplicao principal, em detrimento de todas as demais aplicaes, pois no possvel uma hierarquia mltipla. Como exemplo desta situao, tomemos o caso de um fornecimento de peas.

Banco de Dados

29.68

Ou organizamos o banco de dados tendo como registro pai os dados do fornecedor e os registros das peas como registros filhos (figura 4.6) ou o contrrio (figura 4.7), mas, no podemos ter as duas situaes ao mesmo tempo: F0001 P0001 P0003 F0002 P0002 Fornecedor 1 Rebimboca da parafuseta Pino da grampola Fornecedor 2 Pino da parafuseta ... 45,50 49,00 ... 300,00 ... 45,50 ... 50,00 49,00 ... ... ... ... ... ... ... 300,00 50,00 ... ...

P0003 Pino da grampola Fig. 4.6: O fornecedor o registro pai. P0001 P0002 P0003 Rebimboca da parafuseta F0001 F0002 F0001 Fornecedor 1 Fornecedor 2 Fornecedor 1 Pino da parafuseta Pino da grampola

F0002 Fornecedor 2 Fig. 4.7: A pea o registro pai.

Os valores apresentados nas duas figuras representam o preo que cada fornecedor cobra pela pea fornecida. por este motivo que a pea P0003 tem dois valores diferentes na primeira figura e que os valores foram deslocados para os registros dos fornecedores na segunda. No primeiro caso o projetista do banco de dados considerou mais importante a figura do fornecedor enquanto que no segundo caso seria a pea. A primeira configurao mais eficiente para uma consulta do tipo Quais as peas fornecidas pelo fornecedor tal?, e menos eficiente para uma consulta do tipo Quais os fornecedores da pea tal?. No segundo caso a situao se inverte. Resumindo, no modelo de dados hierrquico o banco de dados projetado para ser mais eficiente com relao a uma aplicao em detrimento de todas as demais. O que era condizente com as necessidades da poca em que o modelo foi criado, que era a criao de um banco de dados para atender a uma aplicao. Quando se tentou usar o mesmo banco de dados para outras aplicaes que o problema apareceu. Outro problema com o modelo hierrquico que no possvel inserir no banco um dado dependente sem que antes tenha sido inserido o dado principal. Por exemplo, se considerarmos a primeira configurao, em que o fornecedor o registro pai e a pea o registro filho, no podemos inserir no banco dados relativos a uma pea para a qual ainda no haja pelo menos um fornecedor. Por outro lado, se eliminarmos do banco um fornecedor que seja o nico fornecedor de uma determinada pea, perderemos os dados sobre essa pea (ao eliminarmos do banco de dados um registro pai, todos os registros filhos deste registro so tambm eliminados). Inicialmente tentou-se solucionar esses problemas com a criao do modelo de dados em rede. Banco de Dados 30.68

4.2 Modelo em rede

O modelo de dados em rede foi desenvolvido por um comit criado para propor um padro para o modelo lgico para o banco de dados. No modelo em rede cada tipo de registro do banco de dados hierrquico foi agrupado em um arquivo diferente e foram introduzidos arquivos auxiliares para efetuar a ligao entre os diversos arquivos do banco de dados. A figura a seguir mostra como ficaria o modelo de dados para fornecedores e peas:
Fornecedor1 Fornecedor2 Arquivo Fornecedor Arquivo de ligao

Pea1

Pea2

Pea3

Arquivo Pea

Fig. 4.8: Estrutura dos arquivos no modelo em rede. Complicado, no? Felizmente, a interpretao desta tralha toda fica por conta do SGBD. Apenas para acompanhar a discusso, vamos destrinchar esta confuso. No arquivo que contm os dados dos fornecedores (chamemos de arquivo fornecedor), o registro do primeiro fornecedor aponta (tem uma indicao) para o registro do segundo fornecedor, que aponta para o terceiro e assim por diante, at o ltimo, que aponta de volta para o primeiro. Ocorre algo semelhante no arquivo peas. O registro da primeira pea aponta para o registro da segunda pea, que aponta para o terceiro etc. e, finalmente, o ltimo aponta para o primeiro. O registro do primeiro fornecedor tem um apontador para o arquivo de ligao. Esse apontador aponta para um registro no arquivo de ligao que por sua vez aponta para a primeira pea fornecida pelo fornecedor1. Para descobrirmos a prxima pea fornecida pelo fornecedor1 basta seguirmos a cadeia no arquivo de ligao e, assim, veremos que o fornecedor1 tambm fornece a pea3. Como, no arquivo de ligao, o registro correspondente pea3 aponta de volta para o primeiro registro, isso indica o fim da seqncia. O arquivo de ligao mostrado na figura acima estabelece a ligao do fornecedor para a pea. Se quisssemos a ligao inversa (da pea para o fornecedor) precisaramos ter um outro arquivo de ligao semelhante a esse. Com esses dois arquivos de ligao, a resposta para uma consulta do tipo Quais as peas fornecidas pelo fornecedor tal? to eficiente quanto para uma consulta do tipo Quais os fornecedores da pea tal?. No modelo em rede podemos inserir dados para uma pea mesmo que ainda no exista fornecedor para a mesma. E, podemos eliminar o nico fornecedor de uma pea sem perder os dados da pea. Apesar de aparentemente muito complicado, como o estabelecimento e a manuteno dessas ligaes fica por conta do SGBD, a complicao no o verdadeiro problema do modelo em rede.

Banco de Dados

31.68

So dois os principais problemas do modelo de dados em rede. Os apontadores que mostramos ao descrever o modelo so referncias s posies fsicas dos registros apontados dentro dos arquivos. Devido s sucessivas inseres e excluses de registros no banco de dados, o desempenho comea a cair, sendo necessrio ento reorganizar fisicamente os arquivos que compem o banco de dados, o que consome algum tempo e recursos computacionais. O outro grande problema desse modelo que podemos ter vrias cadeias de apontadores partindo de um mesmo registro. Por exemplo, a partir do arquivo peas poderamos ter uma cadeia de apontadores para fazer a ligao com o arquivo fornecedor (para podermos determinar quais os fornecedores de uma pea) e outra para o arquivo produto (para podermos determinar em quais produtos a pea usada). E precisamos saber em cada consulta qual cadeia dever ser seguida.

4.3 Modelo relacional

No modelo relacional cada tipo de registro que vimos no modelo hierrquico agrupado em um arquivo, assim como no modelo em rede. No modelo relacional, entretanto, cada arquivo tem o formato de uma tabela de duas dimenses, tais quais as planilhas eletrnicas. Cada tabela (ou relao, por analogia com a matemtica) composta de linhas e colunas. Cada linha representa um objeto do arquivo. No caso do arquivo funcionrio, cada linha representar um funcionrio. Cada coluna da tabela (tambm chamada de campo) ocupada por um tipo de dado (Nome, Departamento, Cargo, Salrio etc.). Apresentamos a seguir a tabela para fornecedores (figura 4.9) e a tabela para peas (figura 4.10): Nome_fornecedor Fornecedor 1 ... ...

Fornecedor 2 ... Fig. 4.9: Tabela fornecedores no modelo relacional. Cdigo_pea P0001 P0002 Nome_pea Pino da parafuseta ... ... ... Rebimboca da parafuseta ...

P0003 Pino da grampola Fig. 4.10: Tabela peas no modelo relacional.

Trs fatos devem ser observados. Em primeiro lugar, note-se que a primeira linha de cada figura foi colocada na figura apenas para facilitar a compreenso. Na realidade no fazem parte das tabelas. Em segundo lugar, note-se que o preo das peas no foi colocado na tabela pea e nem na tabela fornecedor. E, finalmente, note-se que no h qualquer forma de relacionar os fornecedores com as peas. Antes de mostrar como feito o relacionamento entre as tabelas, vamos definir de um modo mais preciso o conceito de tabelas no contexto do modelo relacional. O conceito de banco de dados relacional foi apresentado em 1970 por E. F. Codd. J nesta poca ele previa que a adoo de um modelo relacional de dados... permite o desenvolvimento de uma sub-linguagem universal (para manipulao) de dados..., o que veio a se concretizar com a criao da linguagem SQL (que veremos mais adiante).

Banco de Dados

32.68

Codd descreveu uma tabela como uma matriz retangular com as seguintes propriedades: 1) homognea com relao s colunas, isto , em qualquer coluna selecionada os itens so todos do mesmo tipo, enquanto itens de colunas diferentes no so necessariamente do mesmo tipo. 2) Cada item um nico nmero ou uma cadeia de caracteres (portanto, se tomarmos um item em qualquer linha e coluna, no acharemos um conjunto de nmeros ou um grupo). Posteriormente, as trs propriedades seguintes foram acrescentadas por Carolyn J. Hursch e Jack L. Hursch: 3) Todas as linhas da tabela tm que ser diferentes (no so permitidas linhas duplicadas). 4) A ordem das linhas dentro da tabela no relevante. 5) So atribudos nomes diferentes s colunas da tabela, e a ordem das colunas no relevante, isto , as colunas so identificadas pelo seu nome e no pela sua posio dentro da tabela. Complementando, definimos os termos a seguir para facilitar a compreenso do texto: 1) Uma relao uma tabela. 2) Um atributo (ou campo) ser chamado de coluna. 3) Um nico registro ser chamado de linha. 4) Um valor individual existente na interseo de qualquer linha com coluna ser chamado de dado. Para atender propriedade que diz que no haver linhas duplicadas na tabela cada tabela dever ter pelo menos uma coluna cujos valores sejam diferentes para cada linha. Essa coluna, que servir para identificar os registros da tabela, ser considerada a chave da tabela (o atributo determinante do modelo conceitual). A coluna cdigo_fornecedor exerce essa funo na tabela fornecedor e assim como a coluna cdigo_pea na tabela pea. Para representar o relacionamento entre as tabela criamos uma terceira tabela, que chamaremos de fornece: Cdigo_pea Cdigo_fornecedor P0001 P0002 P0003 F0001 F0002 F0001 Preo 300,00 45,50 50,00

P0003 F0002 49,00 Fig. 4.11: A tabela fornece estabelece a ligao entre as tabelas peas e fornecedor. Como podemos observar na figura acima, a nova tabela foi construda com as colunas cdigo_pea (chave da tabela pea), cdigo_fornecedor (chave da tabela fornecedor) e preo, que indica o preo cobrado pelo fornecedor pela pea em questo.

Banco de Dados

33.68

O modelo de dados relacional resolveu de maneira simples os problemas apresentados pelos modelos anteriores e, devido a isso, tornou-se o modelo de dados padro.

4.1 Exerccios
1) Descreva sucintamente: a) o modelo hierrquico; b) o modelo em rede e c) o modelo relacional. 2) Quais as vantagens e desvantagens de cada um dos trs modelos lgicos de dados? 3) Considerando o modelo relacional de dados, defina: a) tabela; b) linha; c) coluna e d) dado. 4) Estabelea uma analogia entre os elementos de um DER e: a) b) c) d) uma tabela; uma linha de uma tabela; uma coluna de uma tabela e um dado de uma tabela.

5 Projeto de banco de dados relacional

A tecnologia de banco de dados encontra-se hoje em um estgio intermedirio, tendo evoludo muito, desde os primeiros bancos de dados hierrquicos at os atuais bancos de dados relacionais, que uma tecnologia consolidada, e preparando-se para um novo salto rumo tecnologia baseada em objetos. A tecnologia de banco de dados baseada em objetos ainda no est muito disseminada e as anteriores praticamente deixaram de ser usadas. Hoje em dia a grande estrela o banco de dados relacional. Enquanto aguardamos a nova estrela, vamos atacar o banco de dados relacional. Como vimos anteriormente, para desenvolver uma aplicao usando a tecnologia de banco de dados comeamos estudando o ambiente onde o banco de dados ser usado e as necessidades de informao que se espera suprir com o mesmo. Ao longo do estudo procuramos entender como a aplicao deve funcionar e quais os dados sero necessrios para a sua implementao. Nesta fase, de modelagem conceitual, criamos o Modelo de Entidades e Relacionamentos, descrito por meio de um Diagrama de Entidades e Relacionamentos. Passamos, ento, para a fase seguinte, a converso do modelo conceitual no modelo lgico. Usaremos o modelo relacional nesta fase.

5.1 Chaves
Vimos que no modelo relacional os dados so armazenados em tabelas (matrizes retangulares) onde cada linha contm dados referentes a um objeto e cada coluna representa um atributo. Vimos, tambm, que no podemos ter linhas duplicadas nas tabelas e, portanto, pelo menos uma coluna da tabela deve ter valores distintos para cada uma das linhas e que essa coluna recebe o nome de chave da tabela (ou atributo chave).

Banco de Dados

34.68

Um atributo chave , portanto, uma coluna cujos valores servem para identificar de forma unvoca cada uma das linhas da tabela. Para determinarmos qual ser a chave da nossa tabela comeamos verificando quais colunas da tabela atendem ao requisito necessrio (valores distintos). Temos ento as chaves candidatas. Em uma tabela funcionrio, por exemplo, poderamos ter, entre outros atributos, os seguintes: Nome CPF Cargo Nome Depto Verba Depto Salrio Fig. 5.1: Possveis campos da tabela funcionario. ...

Destes atributos, poderamos pensar inicialmente no nome e no cpf como chaves candidatas. Acontece que h uma grande probabilidade de termos mais de um funcionrio com o mesmo nome (podem aparecer alguns Jos da Silva ou Raimundo Nonato). Mas, no podemos raciocinar em termos de probabilidade e sim de possibilidade: basta haver a possibilidade de duplicidade para incapacitar o atributo como chave. Quanto ao atributo cpf, no h possibilidade de duplicidade. Portanto, serve como chave candidata. Entretanto, no o atributo ideal, pois no temos controle sobre sua codificao. Se, por algum motivo, a Secretaria da Receita Federal do Ministrio da Fazenda resolver alterar sua codificao, aumentando o nmero de dgitos do CPF, por exemplo, teremos que alterar o nosso banco. O ideal seria criarmos um atributo especfico com essa finalidade, tal como uma matrcula para os funcionrios. E, teremos a nova tabela: Matrcula Nome CPF Cargo Nome Depto Verba Depto Salrio Fig. 5.2: Segunda verso da tabela funcionario. ...

Temos agora duas chaves candidatas: matrcula e cpf. Pode at acontecer de termos mais de duas chaves candidatas. Dentre elas escolheremos uma como chave primria. As demais chaves candidatas tornam-se, ento chaves secundrias. A chave primria exerce um papel muito importante no modelo relacional, pois por meio dela que estabeleceremos o relacionamento entre as tabelas. No caso de uma tabela que represente um relacionamento, tal qual a tabela fornece (figura 5.3), no temos nenhuma coluna que, sozinha, sirva como chave candidata. Neste caso, precisamos dos valores de duas colunas (cdigo_pea e cdigo_fornecedor) para identificar cada linha. Neste caso usaremos como chave a concatenao das duas colunas e teremos ento uma chave composta. H outras situaes em que precisaremos concatenar duas ou mais colunas para formar a chave, seja ela uma chave primria ou no. Em todos esses casos dizemos que a chave composta. Cdigo_pea Cdigo_fornecedor P0001 P0002 P0003 F0001 F0002 F0001 Preo 300,00 45,50 50,00 49,00

P0003 F0002 Fig. 5.3: Exemplo de chave composta.

Banco de Dados

35.68

Na tabela funcionrio, mostrada na figura 5.2 acima, os contedos dos campos nome depto e verba depto seriam repetidos nas linhas de todos os funcionrios do mesmo departamento, o que constituiria em redundncia. Alm da perda de espao no arquivo, essa redundncia deve ser evitada pelos problemas que causa. Para alterar o campo verba depto, por exemplo, todas as linhas referentes ao mesmo departamento teriam que ser alteradas. Este tipo de redundncia eliminado por meio da normalizao das tabelas, um processo que ser tratado mais adiante. Por enquanto, mostraremos apenas o resultado final da normalizao para exemplificar outro tipo de chave. No processo de normalizao os dados dos departamentos seriam movidos para uma tabela prpria, departamento, e, em seu lugar na tabela funcionrio ficaria a chave da nova tabela para fazer a ligao entre as duas tabelas. Na tabela departamento, a coluna cdigo depto recebe o nome de chave primria. J na tabela funcionrio, recebe o nome de chave estrangeira. Matrcula Nome CPF Cargo Cdigo Depto Salrio ... ...

Cdigo Depto Nome Depto Verba Depto Fig. 5.4: Exemplo de chave estrangeira.

Podemos acessar os dados da tabela funcionrio por ordem crescente dos valores da coluna cpf (ou de qualquer outra coluna). Neste caso a coluna em questo considerada uma chave alternativa (e nesse caso podemos ter duplicidade da chave, pois no se trata de uma chave primria).

5.1.1 Restries de integridade

Para manter a integridade no banco de dados relacional as chaves esto sujeitas a algumas limitaes, conhecidas como restrio de integridade de identidade e restrio integridade referencial. A regra de restrio de integridade de identidade estabelece que nenhum atributo que faa parte de uma chave primria pode ter valor nulo. Um valor nulo diferente do valor zero para um atributo numrico e do caractere espao para um atributo alfanumrico. Um valor nulo um valor inexistente. Como a chave primria serve para identificar de modo unvoco as linhas da tabela ela deve ter sempre um valor vlido. A regra de restrio de integridade referencial estabelece que se uma tabela A possui um atributo T que uma chave estrangeira com relao a uma tabela B (T atributo chave da tabela B) todo valor de T na tabela A deve ter correspondente na tabela B ou, ento, ser nulo. Em algumas situaes no so permitidos nem valores nulos na chave estrangeira. A restrio de integridade referencial impe algumas limitaes durante a eliminao de linhas da tabela. Consideremos as tabelas A e B acima. S poderemos eliminar da tabela B uma linha se o valor da chave T no estiver presente em nenhuma linha da tabela A como chave estrangeira, pois, caso contrrio, estaramos infringindo a regra da restrio de integridade referencial (passaramos a ter na tabela A um valor do atributo T, chave estrangeira, sem correspondente na tabela B). Para eliminar da tabela B a linha em questo, primeiro teramos que eliminar a linha correspondente da tabela A ou alterar o valor do atributo T de A para nulo, se isso for possvel.

Banco de Dados

36.68

5.1.2 Exerccios
1) Considere uma entidade empregados, com os seguintes atributos: matrcula, nome, endereo, cpf, cdigo do departamento, data de nascimento e salrio. Que atributos comporiam as chaves candidatas, a chave primria e as chaves secundrias? 2) Considere uma entidade automvel, com os seguintes atributos: nmero da placa, ano de fabricao, marca, cor, modelo e nmero do chassi. Que atributos comporiam as chaves candidatas, a chave primria e as chaves secundrias? 3) Considere uma entidade notas fiscais, representando as notas fiscais emitidas por uma empresa, com os seguintes atributos: nmero da nota fiscal, data de emisso, cgc do cliente, razo social do cliente e valor total da nota. Que atributos comporiam as chaves candidatas, a chave primria e as chaves secundrias? 4) Considere uma entidade notas fiscais, representando as notas fiscais recebidas por uma empresa, com os seguintes atributos: nmero da nota fiscal, data de emisso, cgc do fornecedor, razo social do fornecedor e valor total da nota. Que atributos comporiam as chaves candidatas, a chave primria e as chaves secundrias?

5.2 Normalizao
Em 1970, E. F. Codd apresentou a primeira forma normal para tabelas no modelo relacional, seguida em 1972 pela segunda e pela terceira formas normais e complementadas e aperfeioadas por outros autores a partir da. A normalizao das tabelas serve para diminuir a redundncia dos dados nas tabelas e evitar a anomalia da atualizao. Veremos, atravs de exemplos, como esses problemas ocorrem e como usar a normalizao para contorn-los. Usaremos o mais popular exemplo para explicar a normalizao: uma nota fiscal (omitindo vrios detalhes para simplificar):
Empresa Preo Bom Pr Cachorro Cliente: Fulano de Tal End: Rua Sobe e Desce, 35 UF: Descrio Coleira Simples Rao Balanceada Focinheira Osso de Couro Shampoo Antipulgas Cidade: Miracema do Norte Cdigo 1256 0237 2549 0788 0036 Quant Unid 1 PCA 40 KG 1 PCA 3 PCA 2 FCO CPF/CGC RJ Data: Preo Unit 7,25 4,30 12,90 2,50 6,40 Bairro: Tatu de Botas 25/03/2007 Preo Total 7,25 172,00 12,90 7,50 12,80 No 001234 111.111.111-11

Total da Nota:

212,45

Fig. 5.5: Exemplo de uma nota fiscal. Vamos, inicialmente, criar uma tabela, que chamaremos de nota_fiscal, para armazenar esses dados, sem grandes preocupaes. Como o espao no papel pequeno

Banco de Dados

37.68

para acomodar todas as colunas da tabela, a mesma ser dividida, apenas para efeito de apresentao, em tantas partes quantas se fizerem necessrias. Tambm, para efeito de apresentao, colocaremos na primeira linha da tabela o nome das colunas. O primeiro problema que encontramos com relao aos dados do corpo da nota fiscal (os dados relativos aos produtos comprados), que um dado com repeties (atributo multivalorado). Consideremos o cdigo do produto. Se usarmos uma coluna para cada ocorrncia do cdigo (figura 5.6) precisaremos tantas colunas quantas forem as linhas da nota fiscal. Como nem todas as notas fiscais tero todas as linhas preenchidas, estaremos desperdiando espao na tabela. Cdigo1 Cdigo2 ... 1256 237 ... Fig. 5.6: Uma coluna para cada cdigo de produto. Outra soluo seria criarmos uma linha na tabela para cada linha efetivamente preenchida da nota fiscal e repetirmos os demais campos: Nmero Nome_cliente CPF_CGC 001234 001234 001234 001234 Endereo Bairro Tatu de Botas Tatu de Botas Tatu de Botas Tatu de Botas Tatu de Botas Fulano de Tal 11111111111 R. Sobe e Desce, 35 Fulano de Tal 11111111111 R. Sobe e Desce, 35 Fulano de Tal 11111111111 R. Sobe e Desce, 35 Fulano de Tal 11111111111 R. Sobe e Desce, 35

001234 Fulano de Tal 11111111111 R. Sobe e Desce, 35 Fig. 5.7: Parte 1 da tabela nota_fiscal. Cidade Miracema do Norte Miracema do Norte Miracema do Norte Miracema do Norte UF Data RJ 25/03/2007 RJ 25/03/2007 RJ 25/03/2007 RJ 25/03/2007

Miracema do Norte RJ 25/03/2007 Fig. 5.8: Parte 2 da tabela nota_fiscal. Cd 1256 0237 2549 0788 Qtd Unid Descrio 1 Pca 40 Kg 1 Pca 3 Pca Coleira simples Rao balanceada Focinheira Osso de couro Preco_Unit Preco_Tot Tot_Nota 7,25 4,30 12,90 2,50 6,40 7,25 172,00 12,90 7,50 12,80 212,45 212,45 212,45 212,45 212,45

0036 2 Fco Shampoo antipulgas Fig. 5.9: Parte 3 da tabela nota_fiscal. Essa soluo ainda no a ideal.

Banco de Dados

38.68

5.2.1 Primeira forma normal

A primeira forma normal estabelece que uma tabela estar na primeira forma normal se existir um e apenas um valor para cada coluna, ou seja, a tabela no poder conter grupos repetitivos (atributos multivalorados). A nota fiscal contm atributos multivalorados (os itens do corpo da nota fiscal, contendo os campos desde cdigo at preo total). Em lugar de duplicar em cada linha da tabela os demais campos, a soluo consiste em transferir os atributos multivalorados para uma outra tabela. Nesta nova tabela (item_nota) colocamos tambm uma cpia da chave primria da tabela original para fazer a ligao entre as duas tabelas: Nmero 001234 001234 001234 001234 Cd 1256 0237 2549 0788 Qtd Unid Descrio 1 Pca 40 Kg 1 Pca 3 Pca Coleira simples Rao balanceada Focinheira Osso de couro Shampoo antipulgas Preco_Unit Preco_Tot 7,25 4,30 12,90 2,50 6,40 7,25 172,00 12,90 7,50 12,80

001234 0036 2 Fco Fig. 5.10: Tabela item_nota.

A chave primria da tabela item_nota ser composta pela concatenao das colunas nmero e cd. A tabela nota_fiscal ficaria, ento sem os dados do corpo da nota fiscal: Nmero Nome_cliente CPF_CGC Endereo Bairro 001234 Fulano de Tal 11111111111 R. Sobe e Desce, 35 Tatu de Botas Fig. 5.11: Tabela nota_fiscal na primeira forma normal (parte 1). Cidade UF Data Tot_Nota Miracema do Norte RJ 25/03/2007 212,45 Fig. 5.12: Tabela nota_fiscal na primeira forma normal (parte 2). As tabelas nota_fiscal e item_nota esto agora na primeira forma normal. Se implementssemos as tabelas como mostrado acima, alm do desperdcio de espao no arquivo facilmente observvel, devido redundncia, teramos tambm os problemas conhecidos como anomalia de atualizao: anomalia de incluso: para incluir um novo cliente no banco de dados, o cliente tem que estar associado a alguma nota fiscal; anomalia de excluso: se excluirmos o nico cliente que comprou um determinado produto perderemos os dados referentes a esse produto; anomalia de alterao: caso o fornecedor de algum produto decida alterar o preo do produto ser necessrio percorrer toda a tabela alterando o preo do produto em cada uma das linhas em que ele aparecer. Da a necessidade de normalizar as tabelas de acordo com outras formas normais. Neste ponto interessante uma observao para mostrar a importncia da modelagem conceitual. As tabelas foram montadas de propsito para exemplificar o processo de normalizao. Entretanto, esse seria o resultado que obteramos se

Banco de Dados

39.68

partssemos direto para montar as tabelas. Ou, por outro lado, fazendo inicialmente a modelagem conceitual no chegaramos a esse tipo de tabela, pois na modelagem conceitual cada entidade contm apenas dados relativos a um nico objeto. E no teramos misturado em uma mesma tabela dados do cliente, dos produtos e da venda. bvio que a modelagem conceitual no resolver todos os problemas, mas ajudar bastante.

5.2.2 Dependncia funcional

Antes de apresentar as outras formas normais necessrio introduzir o conceito de dependncia funcional. A maior parte da teoria de normalizao de tabelas est baseada neste conceito. Vamos acrescentar mais algumas linhas nas tabelas nota_fiscal e item_nota, isto , vamos acrescentar mais algumas notas fiscais no nosso banco para melhorar o exemplo. Nmero Nome_cliente CPF_CGC 001234 001238 001239 Jos da Silva Joo Nonato Endereo Bairro Tatu de Botas Tatu de Cima Tatu de Baixo Tatu de Botas Fulano de Tal 11111111111 R. Sobe e Desce, 35 22222222222 Pa da Matriz, 44 33333333333 Av. Litornea, 55

001241 Fulano de Tal 11111111111 R. Sobe e Desce, 35 Fig. 5.13: Tabela nota_fiscal (parte1). Cidade Piracanduva Novo Horizonte UF PI Data 25/03/2007 28/03/2007 Tot_Nota 212,45 114,30 28,75 3,20 Miracema do Norte RJ

MG 30/03/2007

Miracema do Norte RJ 25/06/2007 Fig. 5.14: Tabela nota_fiscal (parte2). Nmero 001234 001234 001234 001234 001234 001238 001238 001238 001239 001239 Cd 1256 0237 2549 0788 0036 0237 2549 0788 1256 0237 Qtd Unid Descrio 1 Pca 40 Kg 1 Pca 3 Pca 2 Fco 20 Kg 2 Pca 1 Pca 1 Pca 5 Kg

Preco_Unit Preco_Tot 7,25 4,30 12,90 2,50 6,40 4,30 12,90 2,50 7,25 4,30 3,20 7,25 172,00 12,90 7,50 12,80 86,00 25,80 2,50 7,25 21,50 3,20

Coleira simples Rao balanceada Focinheira Osso de couro Shampoo antipulgas Rao balanceada Focinheira Osso de couro Coleira simples Rao balanceada Shampoo comum

001241 0035 1 Fco Fig. 5.15: Tabela item_nota.

Banco de Dados

40.68

As tabelas nota_fiscal e item_nota esto na primeira forma normal, mas ainda possuem muitos dados redundantes, que dificultam a atualizao. Em uma tabela qualquer uma coluna (ou conjunto de colunas) B funcionalmente dependente de uma coluna A se para cada valor de A o valor de B for sempre o mesmo. Por exemplo, na tabela nota_fiscal, todas as colunas so funcionalmente dependentes da coluna nmero (isso lgico, pois a coluna nmero a chave primria da tabela e, portanto, no h repetio). Ainda na tabela nota_fiscal, toda vez que aparece o nome Fulano de Tal na coluna nome_cliente, os valores das colunas cpf_cgc, endereo, bairro, cidade e uf so sempre os mesmos: 11111111111, R. Sobe e Desce, 35, Tatu de Botas, Miracema do Norte, RJ (apenas para efeito de exemplo no consideraremos o fato de poder existir dois clientes com o mesmo nome). Portanto, as colunas cpf_cgc, endereo, bairro, cidade e uf so funcionalmente dependentes da coluna nome_cliente. Na tabela item_nota as colunas unid, descrio e preo_unit so funcionalmente dependentes da coluna cd. claro que no determinaremos a existncia dessas dependncias examinando o contedo das tabelas, e sim atravs do estudo do relacionamento entre os atributos durante a modelagem conceitual (para um dado cliente o cpf/cgc, o endereo etc. sero sempre os mesmos). Em uma tabela cuja chave primria seja composta (concatenao de duas ou mais colunas) podem ocorrer duas situaes: uma ou mais colunas serem dependentes apenas de uma parte da chave (dependncia funcional parcial) ou da chave completa (dependncia funcional total). Na tabela item_nota temos exemplo das duas situaes. A chave primria da tabela composta pelos campos nmero e cd. Os campos unid, descrio e preo_unit so dependentes funcionais apenas da coluna cd, enquanto que a coluna qtd dependente funcional de todas as colunas da chave primria. No exemplo que citamos anteriormente, da dependncia funcional das colunas cpf_cgc, endereo, bairro, cidade e uf da tabela nota_fiscal com relao coluna nome_cliente ocorre uma situao diferente. Neste caso, as colunas em questo so funcionalmente dependentes de uma coluna (cliente) que no faz parte da chave primria da tabela (nmero), mas que funcionalmente dependente da chave primria (a coluna cliente no faz parte da chave primria, mas funcionalmente dependente da chave primria). A esse tipo de dependncia damos o nome de dependncia funcional transitiva.

5.2.3 Segunda forma normal

A teoria da normalizao estabelece que uma tabela estar na segunda forma normal se e somente se estiver na primeira forma normal e no possuir nenhuma coluna que seja dependente funcional parcial da chave primria. As duas tabelas que estamos tratando (nota_fiscal e item_nota) esto na primeira forma normal, mas a tabela item_nota no est na segunda forma normal, pois as colunas unid, descrio e preo_unit so dependentes funcionais apenas da coluna cd. Para colocar a tabela item_nota na segunda forma normal basta movermos as colunas que so dependentes funcionais parciais da chave primria para uma nova Banco de Dados 41.68

tabela. A nova tabela (produto) ter como chave primria a coluna (ou colunas) da qual as colunas movidas so funcionalmente dependentes (no caso a coluna cd). Apresentamos a seguir as tabelas aps a normalizao. Nmero Cd Qtd Preco_Tot 001234 001234 001234 001234 001234 001238 001238 001238 001239 001239 1256 0237 2549 0788 0036 0237 2549 0788 1256 0237 1 40 1 3 2 20 2 1 1 5 7,25 172,00 12,90 7,50 12,80 86,00 25,80 2,50 7,25 21,50

001241 0035 1 3,20 Fig. 5.16: Tabela item_nota na Segunda Forma Normal. Cd 0035 0036 0237 0788 1256 Unid Descrio Fco Fco Kg Pca Pca Shampoo comum Shampoo antipulgas Rao balanceada Osso de couro Coleira simples Preco_Unit 3,20 6,40 4,30 2,50 7,25

2549 Pca Focinheira 12,90 Fig. 5.17: Tabela produto, criada na normalizao da tabela item_nota.

5.2.4 Terceira forma normal

Na tabela nota_fiscal (repetida abaixo para facilitar a visualizao) as colunas cpf_cgc, endereo, bairro, cidade e uf so dependentes funcionais transitivos da coluna nome_cliente. Essa dependncia funcional provoca as anomalias de atualizao j citadas: anomalia de incluso: para incluir um novo cliente no banco de dados, o cliente tem que estar associado a alguma venda; anomalia de excluso: se excluirmos o nico cliente que comprou um determinado produto perderemos os dados referentes a esse produto; anomalia de alterao: caso um cliente mude de endereo ser necessrio percorrer toda a tabela alterando o endereo do cliente em cada uma das linhas em que ele aparecer.

Banco de Dados

42.68

Nmero Nome_cliente CPF_CGC 001234 001238 001239 Jos da Silva Joo Nonato

Endereo

Bairro Tatu de Botas Tatu de Cima Tatu de Baixo Tatu de Botas

Fulano de Tal 11111111111 R. Sobe e Desce, 35 22222222222 Pa da Matriz, 44 33333333333 Av. Litornea, 55

001241 Fulano de Tal 11111111111 R. Sobe e Desce, 35 Fig. 5.18: Tabela nota_fiscal (parte1). Cidade Piracanduva Novo Horizonte UF PI Data 25/03/2007 28/03/2007 Tot_Nota 212,45 114,30 28,75 3,20 Miracema do Norte RJ

MG 30/03/2007

Miracema do Norte RJ 25/06/2007 Fig. 5.19: Tabela nota_fiscal (parte2).

A teoria da normalizao estabelece que uma tabela estar na terceira forma normal se e somente se estiver na segunda forma normal e no possuir nenhuma coluna que seja dependente funcional transitiva de outra coluna. Para colocar a tabela nota_fiscal na terceira forma normal basta movermos as colunas com dependncia funcional transitiva, juntamente com a coluna da qual so dependentes, para uma outra tabela. A coluna da qual as outras so dependentes ser a chave primria da nova tabela e substituir as colunas movidas na tabela original. No presente caso a chave primria da nova tabela seria coluna nome_cliente. Entretanto, essa no uma boa escolha para chave, pois podemos ter dois ou mais clientes com o mesmo nome. Portanto, criaremos uma nova coluna, codigo_cliente, para ser a chave primria da nova tabela e, neste caso, a coluna nome_cliente se tornar tambm dependente da coluna cdigo_cliente e ser movida tambm para a nova tabela. Daremos nova tabela o nome de cliente. Apresentamos a seguir as tabelas aps a modificao. Nmero Cdigo_Cliente Data 001234 001238 001239 20030001 20040025 20070032 25/03/2007 28/03/2007 30/03/2007 Tot_Nota 212,45 114,30 28,75 3,20 Endereo

001241 20030001 25/06/2007 Fig. 5.20: Tabela nota_fiscal. Cdigo_Cliente Nome_cliente CPF_CGC 20030001 20040025 Jos da Silva

Fulano de Tal 11111111111 R. Sobe e Desce, 35 22222222222 Pa da Matriz, 44

20070032 Joo Nonato 33333333333 Av. Litornea, 55 Fig. 5.21: Tabela cliente (parte 1).

Banco de Dados

43.68

Bairro

Cidade

UF PI MG

Tatu de Botas Miracema do Norte RJ Tatu de Cima Piracanduva Tatu de Baixo Novo Horizonte Fig. 5.22: Tabela cliente (parte 2).

5.2.5 Outras formas normais

A teoria da normalizao de tabelas no modelo relacional prev outras formas normais: a Forma normal de Boyce/Codd, a Quarta forma normal e a Quinta forma normal. Entretanto, essas formas normais tratam de casos muito especficos e podem ser tratados de forma diferente. Na maioria dos casos apenas a aplicao das trs primeiras formas normais suficiente para produzir tabelas normalizadas. Por esse motivo no entraremos em detalhes a respeito dessas outras formas normais. Elas esto citadas aqui para servir de referncia. Se houver necessidade, ser fcil encontrar a explanao e exemplos na literatura.

5.2.6 Roteiro para a normalizao das tabelas

Voltamos a insistir no fato: se a modelagem conceitual for bem feita, teremos pouco trabalho na fase de normalizao. As tabelas j estaro praticamente normalizadas e restar apenas o trabalho de verificao e, eventualmente, alguma complementao. De todo modo, vamos apresentar aqui um roteiro para a verificao e complementao da normalizao das tabelas. Esse roteiro deve ser aplicado a cada uma das tabelas. Inicialmente verificamos se a tabela possui grupos repetitivos. Se isso ocorrer a tabela no se encontra na primeira forma normal. Devemos, ento, pass-la para a primeira forma normal, conforme foi explicado ao tratarmos da primeira forma normal. Com a tabela j na primeira forma normal efetuamos a verificao relativa segunda forma normal. Para tanto examinamos as tabelas com chaves primrias compostas a procura de colunas com dependncia funcional parcial da chave primria. Se houver alguma coluna nesta situao porque a tabela no est na segunda forma normal. Novamente, devemos proceder como foi descrito, para pass-la para a segunda forma normal. Finalmente, com a tabela na segunda forma normal verificamos se h alguma coluna com dependncia funcional transitiva com relao a alguma coluna que no faa parte da chave primria. Se isso ocorrer porque a tabela no est na terceira forma normal e deve ser corrigida, como foi descrito no item relativo a essa forma normal. Feito isso, salvo algum daqueles casos especficos citados nas outras formas normais, as nossas tabelas estaro normalizadas e poderemos, ento, implementar o nosso banco de dados.

Banco de Dados

44.68

5.2.7 Exerccios
1) Para que efetuamos a normalizao das tabelas? 2) Descreva e exemplifique as anomalias de atualizao. 3) O que dependncia funcional? 4) Como se classificam as dependncias funcionais? Exemplifique. 5) O que indica que uma tabela no est na Primeira Forma Normal? 6) O que indica que uma tabela no est na Segunda Forma Normal? 7) O que indica que uma tabela no est na Terceira Forma Normal? 8) Efetue a normalizao da tabela a seguir, de acordo com as trs primeiras formas normais: Parte 1 da tabela: Matrcula Nome_Aluno Identidade 000001 000001 000001 000002 000002 Aluno 1 Aluno 1 Aluno 1 Aluno 2 Aluno 2 Endereo Bairro Bairro 1 Bairro 1 Bairro 1

11111111111 R. Um, 11 11111111111 R. Um, 11 11111111111 R. Um, 11

22222222222 R. Dois, 22 Bairro 2 22222222222 R. Dois, 22 Bairro 2

Parte 2 da tabela: Cidade UF Data_Ingresso Cd_Curso Nome_Curso Cidade 1 RJ Cidade 1 RJ Cidade 1 RJ 25/03/2007 25/03/2007 25/03/2007 C01 C01 C01 C01 C01 Curso 1 Curso 1 Curso 1 Curso 1 Curso 1

Cidade 2 MG 25/03/2006 Cidade 2 MG 25/03/2006

Parte 3 da tabela: Cd_Disciplina Nome_Disciplina Media_Disc Creditos_Disc Total_Creditos D001 D003 D005 D001 D002 Disciplina 01 Disciplina 03 Disciplina 05 Disciplina 01 Disciplina 02 7,25 5,20 6,50 8,00 7,00 3 2 3 3 2 8 8 8 5 5

6 Estudo de caso (parte 2) Modelo lgico de dados

A criao do modelo lgico de dados consiste em traduzir o modelo conceitual do sistema para uma das trs arquiteturas de banco de dados: o modelo hierrquico, o modelo em rede ou o modelo relacional. Como j foi citado, usaremos o modelo relacional na modelagem lgica. Banco de Dados 45.68

No modelo relacional os dados (os atributos do modelo conceitual) so armazenados em tabelas. Assim, as entidades (e os relacionamentos que possurem atributos prprios) se transformaro em tabelas do modelo lgico. Voltando ao nosso estudo de caso, temos as seguintes entidades, com os respectivos atributos (ver Cap. 3): fornecedores (identificao do fornecedor e o seu nome) produtos (a identificao do produto, a descrio do produto, a unidade de medida do produto, a quantidade em estoque e o preo de venda do produto) pedido_compra_fornecedores (a identificao do pedido de compra, a identificao do fornecedor, a data de entrega dos produtos que constam do pedido e um cdigo para indicar a situao do pedido) clientes (a identificao do cliente e o nome do cliente) pedidos_compra_cliente (a identificao do pedido, a identificao do cliente, a data do pedido, a forma de pagamento, a situao do pedido e a identificao do vendedor responsvel pelo pedido) vendedor (a identificao do vendedor e o nome do vendedor) notas_fiscais (o nmero da nota fiscal, o nmero do pedido de compra relacionado nota fiscal e a data de emisso da nota fiscal) Um nico relacionamento possui atributo prprio: oferecem (o preo oferecido para o produto)

Apesar de no ser obrigatrio, muito importante que se adote um padro para a criao dos nomes dos atributos. Como agora j estamos nos aproximando do armazenamento fsico dos dados no banco de dados importante que comecemos a usar nomes curtos e que lembrem o significado do atributo. Por exemplo, no lugar de identificao do fornecedor, usaremos cd_fornecedor (o prefixo cd indicando cdigo, no sentido de identificador nico). Para data usaremos o prefixo dt e assim por diante. Apresentamos a seguir as tabelas e, em seguida, chamaremos a ateno para alguns detalhes (o * junto ao nome de um atributo indica que ele um atributo chave se houver mais de um atributo com a mesma caracterstica na tabela porque se trata de uma chave composta). Fornecedores *cd_fornecedor nome_fornecedor Produtos *cd_produto desc_produto cd_unid_med qt_estoque preco_unit Fig. 6.1: Tabelas fornecedores, produtos, unid_med e clientes. Unid_Med *cd_unid_med desc_unid_med Clientes *cd_cliente nome_cliente

Banco de Dados

46.68

Pedidos_ Fornecimento *nped_fornecedor cd_fornecedor dt_entrega situao

Pedidos_ Clientes *nped_cliente cd_cliente dt_pedido forma_pagamento situao

Vendedores *cd_vendedor nome_vendedor

Notas_ Fiscais *nnfiscal nped_cliente dt_emissao

cd_vendedor Fig. 6.2: Tabelas pedidos_fornecimento, pedidos_clientes, vendedores e notas_fiscais. Cotacoes_ Produtos *cd_fornecedor *cd_produto preco_oferecido Fig. 6.3: Tabela cotacoes_produto. Em cada tabela foi colocado o conjunto mnimo de atributos, para no alongar demais o texto. Por exemplo, na tabela fornecedores normalmente teramos outros atributos, tais como o endereo, o nmero de inscrio no CNPJ etc. A tabela unid_med foi criada para evitar que a descrio da unidade de medida, um texto, se repetisse vrias vezes na tabela produtos. A chave da nova tabela ento colocada na tabela produtos como chave estrangeira. Apenas para melhorar a compreenso, demos o nome de cotacoes_produto para a tabela que representa o relacionamento oferecem entre as entidades fornecedores e produtos. Quando temos no modelo conceitual um relacionamento da ordem N:1, colocamos na entidade do lado N do relacionamento a chave primria da outra entidade para representar o relacionamento no modelo relacional. Por exemplo, para representar o relacionamento recebem entre as entidades pedidos_fornecimento (lado N) e fornecedores (lado 1) colocamos na tabela pedidos_fornecimento o atributo cd_fornecedor, que a chave primria da tabela fornecedores. Quando temos no modelo conceitual um relacionamento da ordem N:N, mesmo que o relacionamento no tenha atributos prprios, criamos uma tabela para representar o relacionamento. A chave primria da nova tabela ser composta pelas chaves primrias das duas tabelas relacionadas (uma chave composta). Por exemplo, para representar o relacionamento contm entre as entidades pedidos_fornecimento e produtos criamos a tabela itens_pedidos_fornecimento, cuja chave primria ser composta pelos campos nped_fornecedor (chave primria da tabela pedidos_fornecimento) e cd_produto (chave primria da tabela produtos). Da mesma forma, criamos as tabelas itens_pedido_cliente, para representar o relacionamento entre pedidos_clientes e produtos, e itens_nota_fiscal para representar o relacionamento entre notas_fiscais e produtos (figura 6.4).

Banco de Dados

47.68

Itens_Pedido_Fornecimento *nped_fornecedor *cd_produto preco_unit

Itens_Pedido_Cliente *nped_cliente *cd_produto qt_comprada

Itens_Nota_Fiscal *nnfiscal *cd_produto nped_cliente

qt_pedida preco_unit Fig. 6.4: Tabelas itens_pedido_fornecimento, itens_pedidos_clientes e itens_nota_fiscal.

7 SQL
Quando E. F. Codd apresentou o conceito do banco de dados relacional em 1970, ele sugeriu que a adoo de um modelo relacional de dados... permite o desenvolvimento de uma sub-linguagem universal (para manipulao) de dados..., mas, embora tenha indicado os requisitos e as vantagens de tal linguagem, no a criou. Em 1974, D. D. Chamberlin e R. F. Boyce sugeriram a forma de uma linguagem de consulta estruturada, chamada na poca de SEQUEL. Aps uma srie de desenvolvimentos e contribuies de outros autores o nome da linguagem foi alterado para SQL e ela foi utilizada como linguagem de consulta para o banco de dados que a IBM estava desenvolvendo na poca, o Sistema R, precursor do DB2. A partir da a linguagem SQL (Structured Query Language Linguagem de Consulta Estruturada) foi tendo cada vez mais aceitao, tornando-se um padro de fato no mundo dos bancos de dados relacionais e finalmente, em 1982, um padro oficial do American National Standard Institute (ANSI) para o ambiente relacional. A linguagem SQL mostrou-se to bem projetada que, de uma simples Linguagem de Manipulao de Dados (DML, em ingls) evoluiu tambm para uma Linguagem de Definio de Dados (DDL, em ingls). Ou seja, usada hoje em dia no apenas como linguagem de consultas a um banco de dados relacional, mas, tambm, como linguagem para a criao e manuteno de um banco de dados relacional. A linguagem SQL pode ser usada de forma interativa: podemos efetuar uma consulta aos dados de um banco de dados relacional usando diretamente comandos SQL, sem necessidade de criar um programa para isso e nem usar uma aplicao previamente desenvolvida. Podemos usar comandos SQL dentro de programas desenvolvidos em uma outra linguagem para acessar os dados de um banco de dados relacional. O responsvel pela administrao do banco de dados pode usar comandos SQL para realizar suas tarefas (criar tabelas, eliminar tabelas, criar vises etc.). A linguagem SQL pode ser usada em um ambiente cliente/servidor de banco de dados para a comunicao entre o programa cliente (no lado do usurio) e o computador contendo o servidor de banco de dados (que armazena os dados do banco de dados). tambm usada para a comunicao de dados em sistemas de banco de dados distribudos.

7.1 Elementos da linguagem SQL

Como toda linguagem, na SQL tambm temos um vocabulrio (as palavras usadas na linguagem) e uma sintaxe (as regras para a construo de frases na linguagem, neste caso chamadas de comandos). Banco de Dados 48.68

No vocabulrio da SQL temos, basicamente, os nomes das colunas das tabelas (definidos pelo administrador do banco de dados), constantes (numricas e literais), operadores (que indicam as operaes que sero efetuadas nas expresses, tais como os operadores aritmticos e os operadores lgicos) e algumas palavras que possuem um significado especfico. As palavras que possuem significado especfico na linguagem so chamadas de palavras-chaves. As palavras-chaves so tambm palavras reservadas da linguagem, isto , no podem ser usadas para dar nomes a tabelas, colunas etc.

7.1.1 Palavras-chaves
Existem atualmente vrios dialetos da SQL. Vamos usar aqui o padro ANSI. A tabela a seguir mostra as palavras-chaves da SQL: All AVG Check Current Desc Exists Go Insert Max Of Precision Schema SQL Union And Begin Close Cursor Distinct Fetch GOTO Int Min On Privileges Section Sqlcode Unique Any Between Commit Dec Double Float Grant Integer Module Open Procedure Select Sqlerror Update As By Continue Decimal End For Group Into Not Option Public Set Sum User Asc Char Count Declare Escape Found Having Is Null Or Real Smallint Table Values Authorization Character Create Delete Exec From In Like Numeric Order Rollback Some To View

Whenever Where With Work Fig. 7.1: Palavras-chaves do padro ANSI da SQL.

7.1.2 Comandos
Na tabela a seguir apresentamos os comandos bsicos da SQL. A sintaxe de alguns comandos ser apresentada mais adiante: /* ... */ ALTER TABLE COMMENT COMMIT Comentrio colocado dentro ou antes de um comando SQL. Inclui ou redefine uma coluna em uma tabela existente. (No consta do padro ANSI da SQL.) Inclui no dicionrio de dados um comentrio relativo a uma tabela ou uma coluna. Efetiva no banco de dados (tornando permanentes) as modificaes que j foram completadas.

Banco de Dados

49.68

CREATE INDEX Cria um ndice para uma tabela. CREATE TABLE Cria uma tabela e define suas colunas e outras propriedades. CREATE VIEW DELETE DROP GRANT Define uma viso sobre uma ou mais tabelas e/ou sobre outras vises. Exclui linhas de uma tabela. Exclui uma tabela, um ndice etc. do banco de dados. Cria identificaes para usurios, atribui senhas, privilgios relativos ao banco de dados e concede aos usurios privilgios relativos a tabelas e vises. Inclui linhas em uma tabela, diretamente ou atravs de uma viso. Revoga privilgios atribudos a usurios relativos ao banco de dados ou ao acesso a tabelas. Desfaz, em caso de falha no sistema, qualquer alterao que ainda no tenha sido efetivada, de modo que a integridade do banco seja mantida. Permite, tambm, ao usurio desfazer qualquer alterao feita no banco de dados antes que tenha sido executado um comando COMMIT. Seleciona linhas e colunas de uma ou mais tabelas. Muda o valor de um ou mais campos de uma tabela.

INSERT REVOKE ROLLBACK

SELECT UPDATE

Fig. 7.2: Comandos bsicos da SQL.

7.1.3 Tipos de dados

A SQL suporta trs tipos de dados principais: char Cadeia com zero ou mais caracteres. Pode conter algarismos, letras, sinais de pontuao etc. Como pode conter algarismos, se o seu contedo for, por exemplo, um nmero inteiro, mesmo assim o formato ser considerado char, ou seja, no poderemos efetuar operaes aritmticas com esse nmero. numeric Um nmero inteiro. float Um nmero real.

7.1.4 Operadores
A SQL suporta os operadores aritmticos (adio, subtrao, multiplicao e diviso), lgicos (AND, OR e NOT), relacionais (=, <>, <, >, <= e >=) e predicados. Um predicado uma condio que aplicada a uma expresso e produzir como resultado um dos seguintes valores: verdadeiro, falso ou ignorado.

Banco de Dados

50.68

So os seguintes predicados usados na SQL: para definir um intervalo (...BETWEEN...AND...), IN (podendo, tambm, ser usado NOT IN), LIKE e NULL, para definir uma quantidade (ALL, SOME e ANY) e EXISTS (podendo, tambm, ser usado NOT EXISTS). A utilizao dos operadores ser apresentada mais adiante.

7.2 Notao
Na apresentao da sintaxe dos comandos, tanto na parte de definio de dados como, mais adiante, na parte de manipulao de dados, usaremos a seguinte conveno: As palavras-chaves sero apresentadas em negrito. As palavras em itlico indicam que devem ser substitudas pelos valores desejados pelo usurio (por exemplo, pelo nome de uma tabela ou pelo nome de uma coluna de uma tabela). Os colchetes, [], indicam que o que est no seu interior um item opcional. As chaves, {}, indicam que dever ser usado um dos itens colocados no seu interior. Ser usado o smbolo | para separar os itens dentro das chaves. As reticncias indicam repetio.

7.3 SQL como linguagem de definio de dados

A SQL pode ser usada pelos usurios administradores do banco de dados nas suas tarefas. Usada dessa forma a SQL se comporta como uma LDD (Linguagem de Definio de Dados). Apresentaremos apenas os comandos usados para as tarefas mais corriqueiras.

7.3.1 Criao de tabelas

Usamos o comando create table para criar as tabelas que comporo o banco de dados. a seguinte a sintaxe do comando: create table nomedatabela ( nome_da_coluna1 nome_da_coluna2 ... nome_da_colunaN tipo_do_dado[(tamanho_do_dado)] [unique] [not null], tipo_do_dado[(tamanho_do_dado)] [unique] [not null], tipo_do_dado[(tamanho_do_dado)] [unique] [not null]);

A clusula unique indica que no pode haver na tabela valores repetidos para a coluna a que ela se aplica. A clusula not null indica que a coluna correspondente no pode ter valor nulo, isto , um campo de preenchimento obrigatrio. Por exemplo: create table funcionario (matricula nome endereco cpf numero_dependentes salario char(6) unique not null, char(30) not null, char(30) not null, char(11) unique not null, numeric, float not null );

Banco de Dados

51.68

7.3.2 Eliminao de tabelas

Usamos o comando drop table para eliminar uma tabela do banco de dados. a seguinte a sintaxe do comando: drop table nomedatabela; Por exemplo: drop table funcionario;

7.4 SQL como linguagem de manipulao de dados

A SQL pode ser usada pelos usurios para manipular os dados armazenados nas tabelas. Usada dessa forma a SQL se comporta como uma LMD (Linguagem de Manipulao de Dados). Com os comandos da SQL podemos inserir, modificar, excluir e acessar dados em um banco de dados relacional. Apresentaremos a seguir os comandos usados nessas tarefas.

7.4.1 Acesso aos dados de uma tabela

O comando select usado para acessar os dados armazenados em uma tabela. Quando usamos o comando select dizemos, tambm, que estamos efetuando uma consulta ao banco de dados. Considera-se que o resultado produzido por um comando select sempre uma tabela, mesmo que composta de um nico valor, isto , uma tabela com uma nica linha e uma nica coluna. a seguinte a sintaxe do comando: select {* | coluna1, coluna2, coluna3,...} from nome_da_tabela [where condio]; A opo * no comando select indica todas as colunas da tabela. Na outra alternativa sero selecionados os dados das colunas especificadas (coluna1, coluna2, coluna3,...). Na clusula where, condio uma expresso cujo valor ser verdadeiro ou falso. Sero selecionadas as linhas da tabela para as quais o valor de condio for verdadeiro e, para essas linhas sero selecionados os valores das colunas especificadas na clusula select. Se a clusula where for omitida, sero selecionadas todas as linhas da tabela. Vejamos alguns exemplos: select * from funcionario; Neste caso a tabela resultante ser formada pelos dados de todas as colunas para cada uma das linhas da tabela funcionario. select matricula, nome, cpf from funcionario; Neste caso a tabela resultante ser formada pelos dados das colunas matricula, nome e cpf para cada uma das linhas da tabela funcionario. select * from funcionario where matricula = 112233; Neste caso a tabela resultante ser formada pela linha (todas as colunas) da tabela funcionario cujo valor para a coluna matricula seja igual a 112233. select matricula, nome, cpf Banco de Dados 52.68

from funcionario where matricula = 112233; Neste caso a tabela resultante ser formada pelos dados das colunas matricula, nome e cpf da linha da tabela funcionario cujo valor para a coluna matricula seja igual a 112233. A expresso que compe a condio da clusula where pode ser bastante complexa, contendo vrios operadores e sub-expresses, permitindo a flexibilidade necessria para acessar qualquer dado que se queira.

7.4.2 Trabalhando com mais de uma tabela simultaneamente

Em um banco de dados relacional os dados ficam distribudos entre vrias tabelas fazendo com que, muitas vezes, seja necessrio manipular dados de mais de uma tabela ao mesmo tempo. A operao que nos permite trabalhar simultaneamente com dados de vrias tabelas o encadeamento (tambm conhecido na literatura com join). H vrias maneiras de efetuar o encadeamento entre as tabelas. Em todas elas o primeiro passo especificar, na clusula from, os nomes de todas as tabelas que participaro do encadeamento: from tabela1, tabela2 Como podemos ter duas colunas com mesmo nome uma em cada tabela que participar do encadeamento, precisamos de uma forma de identificar uma e outra coluna. Para isso usamos os qualificadores.

7.4.2.1

Qualificadores e apelidos

Para usarmos em um comando duas colunas com mesmo nome, pertencendo, porm, a tabelas diferentes basta qualificarmos os nomes das colunas com os nomes das respectivas tabelas: where tabela1.coluna1 = tabela2.coluna1 Neste exemplo, do qual foram omitidos vrios detalhes, a clusula where estabelece que o valor da coluna1 da tabela1 deve ser comparado com o valor da coluna1 da tabela2. Muitas vezes, para aumentar a clareza ou evitar a repetio de nomes muito extensos, usamos apelidos para as tabelas ou para as colunas: from tabela1 t1, tabela2 t2

Banco de Dados

53.68

Neste caso estamos criando o apelido t1 para a tabela1 e o apelido t2 para a tabela2. Podemos, ento usar no comando onde o apelido foi definido (e apenas nesse comando) o apelido como qualificador no lugar do nome da tabela: select t1.*, t2.* from tabela1 t1, tabela2 t2 ... Neste exemplo estamos especificando todas as colunas da tabela1 e todas as colunas da tabela2 por meio dos apelidos (t1.* e t2.*). Podemos, tambm, atribuir apelidos para colunas: select coluna1 Nome do funcionario, coluna2 Salario from funcionario ... Neste caso estamos assumindo que a coluna que contm o nome do funcionrio foi definida na tabela funcionario com o nome de coluna1 e que coluna2 contm o salrio do funcionrio. Ao exibir o resultado da consulta o ttulo da coluna1 seria apresentado como Nome do funcionario e o da coluna2 como Salario. Note-se que, no primeiro caso o apelido foi especificado com a utilizao de apstrofos. Isso se faz necessrio devido existncia de caracteres especiais (diferentes de letras e dgitos) no apelido (a existncia de espaos), o que no ocorre no segundo caso (Salario). Aparentemente esse problema de falta de clareza deveria ser evitado com a escolha adequada dos nomes para as colunas. Isto verdade. Usamos essa situao apenas para exemplificar a utilizao de apelidos para colunas. A situao em que esse recurso se faz mais necessrio quando usamos funes no resultado da consulta.

7.4.2.2

Encadeamento incondicional

O encadeamento incondicional entre duas tabelas produzir como resultado uma tabela que o produto cartesiano das tabelas encadeadas. Por exemplo: select * from tabela1, tabela2; Vamos supor que a tabela1 tenha trs colunas com os nomes a, b e c e a tabela2 tenha, tambm, trs colunas com os nomes d, e e f, e que os contedos das tabelas seja o mostrado a seguir: Tabela 1 a 1 1 2 b 1 2 2 c 1 1 1 d 1 2 3 Tabela 2 e 4 6 8 f 5 7 9

1 2 2 Fig. 7.3: Tabelas para exemplificar o encadeamento incondicional. A tabela resultante seria formada pela combinao de cada linha da tabela1 com todas as linhas da tabela2:

Banco de Dados

54.68

Tabela resultante t1a 1 1 1 1 1 1 2 2 2 1 1 t1b 1 1 1 2 2 2 2 2 2 2 2 t1c 1 1 1 1 1 1 1 1 1 2 2 t2d 1 2 3 1 2 3 1 2 3 1 2 t2e 4 6 8 4 6 8 4 6 8 4 6 t2f 5 7 9 5 7 9 5 7 9 5 7

1 2 2 3 8 9 Fig. 7.4: Tabela resultante do encadeamento incondicional. Se as tabelas que esto sendo encadeadas possuem duas (ou mais) colunas com o mesmo nome, essas colunas so chamadas de colunas comuns. Por exemplo: Tabela 1 a 1 1 2 b 1 2 2 c 1 1 1 c 1 2 3 Tabela 2 d 4 6 8 e 5 7 9

1 2 2 Fig. 7.5: Exemplo de encadeamento incondicional com nomes de colunas repetidos.

Banco de Dados

55.68

Tabela resultante t1a 1 1 1 1 1 1 2 2 2 1 1 t1b 1 1 1 2 2 2 2 2 2 2 2 t1c 1 1 1 1 1 1 1 1 1 2 2 t2c 1 2 3 1 2 3 1 2 3 1 2 t2d 4 6 8 4 6 8 4 6 8 4 6 t2e 5 7 9 5 7 9 5 7 9 5 7

1 2 2 3 8 9 Fig. 7.6: Tabela resultante do encadeamento incondicional com nomes de colunas repetidos.

7.4.2.3

Encadeamento condicional

Vimos, no processo de normalizao, como uma chave estrangeira usada para fazer a ligao entre duas tabelas. Mostramos o exemplo de uma tabela funcionario onde os dados do departamento seriam substitudos pela chave da tabela departamento, que conteria os dados do departamento: Matrcula Nome_Func 123456 123479 Ana Jos ... Cd_Depto d01 d02 d01 ...

123485 Pedro Fig. 7.7: Tabela funcionario. Cd_Depto Nome_Depto d01 Depto 01 d02 Depto 02 Fig. 7.8: Tabela departamento.

Essa situao, muito comum, leva a outra situao tambm muito comum: muitas vezes queremos efetuar o encadeamento de duas tabelas que tm colunas comuns e a condio na clusula where especifica que os valores nas colunas comuns sejam iguais: select funcionario.nome_func, departamento.nome_depto from funcionario, departamento where funcionario.cd_depto = departamento.cd_depto;

Banco de Dados

56.68

A tabela resultante ser composta pelos dados do funcionrio juntamente com os dados do departamento no qual ele est lotado. Matrcula Nome_Func 123456 123479 Ana Jos ... Funcionario. Cd_Depto d01 d02 ... Departamento. Nome_ Cd_Depto Depto d01 d02 Depto 01 Depto 02 Depto 01

123485 Pedro d01 d01 Fig. 7.9: Unindo as tabelas com a clusula where.

7.4.2.4

Encadeamento natural

Devemos notar que, na tabela resultante do exemplo anterior, a coluna cd_depto estar duplicada. Se eliminarmos do encadeamento condicional as colunas duplicadas, obteremos o encadeamento natural: select matricula, nome_func, nome_depto from funcionario, departamento where funcionario.cd_depto = departamento.cd_depto; A tabela resultante ser composta pelos nomes dos funcionrios juntamente com os nomes dos respectivos departamentos. Matrcula Nome_Func Nome_Depto 123456 123479 Ana Jos Depto 01 Depto 02

123485 Pedro Depto 01 Fig. 7.10: Encadeamento natural.

7.4.2.5

Encadeamento no simtrico

Os encadeamentos mostrados at agora so chamados de encadeamentos simtricos. O encadeamento no simtrico ocorre quando estabelecemos na clusula where que as colunas comuns no podem ter valores iguais: select vendedores.*, clientes.* from vendedores, clientes where not vendedores.cidade = clientes.cidade; que equivalente a: select vendedores.*, clientes.* from vendedores, clientes where vendedores.cidade <> clientes.cidade; A tabela resultante em ambos os casos conter a combinao de clientes e vendedores de cidades diferentes.

Banco de Dados

57.68

7.4.2.6

Encadeamento com mais de duas tabelas

Para efetuar o encadeamento com mais de duas tabelas basta usar o operador and na clusula where: select tabela1.*, tabela2.* , tabela3.* from tabela1, tabela2, tabela3 where tabela1.coluna_ligacao = tabela2.coluna_ligacao and tabela1.coluna_ligacao = tabela3.coluna_ligacao;

7.4.3 Insero de dados em uma tabela

O comando insert usado para inserir dados (linhas) em uma tabela j existente. a seguinte a sintaxe do comando: insert into nomedatabela [( nome_da_coluna1, nome_da_coluna2,... )] {values (valor1, valor2,...) | subconsulta}; A lista com os nomes das colunas ser opcional se formos inserir dados em todas as colunas. Neste caso os valores indicados na clusula values (ou na sub-consulta) devem corresponder s colunas da tabela, tanto quanto ordem como quanto ao tipo de dado. Se no quisermos especificar um valor para uma determinada coluna, omitimos o nome da coluna ou usamos o valor null (desde que a coluna no tenha sido definida com a clusula not null). Por exemplo, em uma tabela funcionario definida como: create table funcionario (matricula nome endereco cpf numero_dependentes salario poderamos usar: insert into funcionario values(123456, Jos da Silva, null, 11111111111, 2, 1450.00); ou, ento: insert into funcionario (matricula, nome, cpf, numero_dependentes, salario) values(123456, Jos da Silva, 11111111111, 2, 1450.00); Muitas vezes os dados que queremos inserir so provenientes de uma outra tabela. Neste caso, no lugar da clusula values usamos uma sub-consulta: insert into tabela2 (matricula, nome, endereco, cpf, numero_dependentes, salario) select * from funcionario where matricula = 123456; char(6) unique not null, char(30) not null, char(30) not null, char(11) unique not null, numeric, float not null );

Banco de Dados

58.68

Neste exemplo estamos copiando para tabela2 a linha com os dados do funcionrio cuja matrcula 123456.

7.4.4 Modificao dos dados de uma tabela

O comando update usado para alterar os dados armazenados em uma tabela. a seguinte a sintaxe do comando: update nomedatabela set coluna1 = novo_valor1, coluna2 = novo_valor2, ... colunaN = novo_valorN [where condio]; Por exemplo: update funcionario set salario = 2000.00, numero_dependentes = 3 where matricula = 112233; Neste caso o salrio do funcionrio cujo valor para a coluna matricula 112233 ser alterado para 2000.00 e o nmero de dependentes ser alterado para 3. update funcionario set salario = salario * 1.05; Neste caso os salrios de todos os funcionrios sofrero um acrscimo de 5%.

7.4.5 Eliminao de linhas de uma tabela

O comando delete usado para eliminar linhas de uma tabela. a seguinte a sintaxe do comando: delete from nomedatabela [where condio]; Por exemplo: delete from funcionario where matricula = 112233; Neste caso a linha correspondente ao funcionrio cujo valor para a coluna matricula 112233 ser eliminada da tabela funcionario. delete from funcionario; Neste caso todas as linhas da tabela funcionario sero eliminadas (a tabela ficar vazia). O efeito neste caso diferente do causado pelo comando drop, pois, neste caso, s as linhas da tabela so eliminadas, permanecendo a estrutura da mesma (como se a tabela acabasse de ser criada), enquanto que o comando drop elimina no apenas os dados mas, tambm, a estrutura da tabela.

7.4.6 Um pouco mais sobre a clusula where

A condio estabelecida na clusula where pode assumir expresses bastante sofisticadas, para atender a uma ampla gama de situaes.

Banco de Dados

59.68

A funo da clusula where indicar que linhas sero selecionadas. Alm dos operadores relacionais (=, <>, <, >, <= e >=) e lgicos (AND, OR e NOT), cuja utilizao bvia para qualquer pessoa que conhea alguma linguagem de programao, podemos usar tambm os predicados ...BETWEEN...AND..., IN (podendo, tambm, ser usado NOT IN), LIKE, NULL, ALL, SOME, ANY e EXISTS (podendo, tambm, ser usado NOT EXISTS) e, at mesmo, sub-consultas. Um predicado uma condio que aplicada a uma expresso e produzir como resultado um dos seguintes valores: verdadeiro, falso ou ignorado. Faremos a apresentao dos predicados atravs de exemplos: select matricula, nome from funcionario where salario between 1000.00 and 2000.00; Neste caso estamos selecionando da tabela funcionario as matrculas e os nomes de todos os funcionrios com salrio entre 1000.00 e 2000.00. Poderamos, tambm, combinar o predicado between com o operador not: select matricula, nome from funcionario where salario not between 1000.00 and 2000.00; Neste caso seriam selecionados todos os funcionrios, exceto aqueles com salrio entre 1000.00 e 2000.00. O predicado in apresenta um conjunto de valores e testa se o valor desejado faz parte do conjunto: select matricula, nome from funcionario where matricula in (123456, 112233, 122334); Neste caso seriam selecionados os funcionrios com matrcula 123456, 112233 ou 122334. O mesmo resultado seria obtido com a utilizao do predicado any: select matricula, nome from funcionario where matricula any (123456, 112233, 122334); O predicado like estabelece um padro para comparao, usando o smbolo _ para representar um nico caractere no padro e o smbolo % para representar uma cadeia de caracteres de qualquer tamanho (inclusive tamanho zero): select matricula, nome from funcionario where nome like _aria; Neste caso seriam selecionados todos os funcionrios cujo nome comece com um caractere qualquer seguido dos caracteres aria. select matricula, nome from funcionario where nome like Maria%;

Banco de Dados

60.68

Neste caso seriam selecionados todos os funcionrios cujo nome comece por Maria. select matricula, nome from funcionario where numero_dependentes = null; Neste caso seriam selecionados todos os funcionrios para os quais no tenham sido fornecidos os nmeros de dependentes. select matricula, nome from funcionario where numero_dependentes > all (select numero_dependentes from funcionario where salario > 2000.00); Neste caso seriam selecionados todos os funcionrios com nmero de dependentes maior do que o nmero de dependentes de todos os funcionrios com salrio maior que 2000.00 (os dependentes de cada funcionrio considerado separadamente e no o somatrio do nmero de dependentes). select matricula, nome from funcionario where numero_dependentes > some (select numero_dependentes from funcionario where salario > 2000.00); Neste caso seriam selecionados todos os funcionrios que tenham mais dependentes que algum funcionrio com salrio maior que 2000.00. select clientes.nome from clientes where exists (select cidade from fornecedores where fornecedores.cidade = clientes.cidade); Neste caso seriam selecionados todos os clientes das cidades onde h fornecedores.

7.4.7 Exerccios
1) Escreva, para cada item a seguir, o comando SQL para selecionar os dados pedidos, considerando que foi criada a seguinte tabela: create table funcionario ( matricula char(6) unique not null, nome char(30) not null, endereco char(30) not null, cd_cargo char(3) not null, dt_admissao char(8) not null, dt_nascimento char(8) not null, salario float not null );

Banco de Dados

61.68

a) a matrcula, o nome, a data de admisso e a data de nascimento para todos os funcionrios; b) a matrcula e o nome dos funcionrios com salrio maior que R$ 5.000,00; c) a mdia dos salrios dos funcionrios no cargo de contador (cdigo 123); d) a soma dos salrios de todos os funcionrios da empresa. 2) Escreva o comando SQL para calcular o nmero de atendimentos no setor de ortopedia (cdigo 029), considerando que foi criada a seguinte tabela: create table atendimento ( cd_atendimento char(6) unique not null, dt_atendimento char(8) not null, matr_medico char(6) not null, setor char(3) not null ); 3) Voc foi encarregado de criar um relatrio com a lista de produtos de uma empresa. Para cada produto devem constar: o cdigo do produto, sua descrio e a descrio da unidade de medida. Escreva o comando SQL para selecionar os dados necessrios, considerando que foram criadas as seguintes tabelas: create table produto ( cd_produto desc_produto cd_unid_med create table unid_med ( cd_ unid_med desc_ unid_med char(6) unique not null, char(30) not null, char(3) not null ); char(3) unique not null, char(30) not null );

8 Modelo fsico de dados

na fase de modelagem fsica que criamos o banco de dados propriamente dito, usando um Sistema Gerenciador de Banco de Dados (SGBD). A forma de descrever os arquivos que comporo o banco de dados depende do SGBD. A linguagem de definio de dados, cujos comandos sero usados para definir os arquivos, pode variar muito de um SGBD para outro (h at uma tendncia para usar interfaces grficas), portanto, fica difcil expandir esse tpico sem limitar a um SGBD especfico. Preferimos, ento, deixar esse assunto para a prxima parte do estudo de caso. Entretanto, qualquer que seja o SGBD usado, o administrador do banco de dados geralmente precisa executar outras tarefas nesta fase. Muitas vezes, para melhorar o desempenho do sistema, o administrador resolve colocar os dados nas tabelas de forma diferente da definida no modelo lgico. Isso decidido durante a criao do modelo fsico, pois problemas de desempenho dizem respeito implementao do banco de dados e no devem afetar a criao do modelo lgico. Por exemplo, ele pode dividir a tabela produtos em duas: uma tabela produtos com os dados gerais dos produtos (descrio, unidade de medida etc.) e outra tabela com dados especficos com relao ao estoque (quantidade em estoque e preo unitrio). Outra situao que ocorre quando se deseja restringir o acesso de determinado tipo de usurio ou aplicao. Por exemplo, em um banco de dados usado em um sistema de pessoal o acesso aos salrios pode ser restringido: a aplicao que calcula a folha de pagamento teria acesso aos salrios individuais enquanto que outra aplicao de consulta no teria acesso.

Banco de Dados

62.68

Essas situaes podem ocorrer mesmo depois do sistema pronto. Em quaisquer desses casos essas alteraes teriam que ser transparentes para os usurios. Cada tipo de usurio deve enxergar os dados sempre da mesma forma. Para compatibilizar essas duas necessidades (flexibilidade para alterar a estrutura fsica do banco de dados e estabilidade dos dados para os usurios) usado um recurso chamado de viso.

8.1 Vises
Uma viso funciona como se fosse uma tabela virtual. Para o usurio (ou aplicao) que usa a viso tudo se passa como se a tabela existisse realmente no banco de dados. Na verdade a viso apenas um mecanismo de acesso aos dados do banco de dados. As vises geralmente so implementadas por meio de comandos create view da SQL: create view nomedavisao [(nome_coluna1_visao, nome_coluna2_visao, ..., nome_colunaN_visao)] as select nome_da_coluna1, nome_da_coluna2, ..., nome_da_colunaN from nome_da_tabela [where condio]; nome_coluna1_visao, nome_coluna2_visao etc. devem ser usados se quisermos usar na viso nomes de colunas diferentes dos nomes existentes nas tabelas originais. Consideremos as tabelas criadas pelos comandos: create table tabela1 ( coluna1 numeric, coluna2 numeric, coluna3 numeric); create table tabela2 ( coluna1 numeric, coluna4 numeric, coluna5 numeric); Neste exemplo estamos considerando que as colunas com nome coluna1 de ambas as tabelas correspondem aos mesmos atributos. Podemos criar uma viso contendo apenas algumas colunas de uma tabela: create view visao1 as select coluna1, coluna3 from tabela1; A partir da podemos usar viso1 como se fosse uma tabela: select * from visao1; Ou, ento: select * from visao1 where coluna1 = 35;

Banco de Dados

63.68

Podemos criar uma viso para selecionar algumas linhas de uma tabela: create view visao2 as select * from tabela1 where coluna1 <> 52; Podemos criar uma viso para selecionar algumas colunas de determinadas linhas de uma tabela: create view visao3 as select coluna1, coluna3 from tabela1 where coluna1 <> 52; Se o dado armazenado na coluna2 fosse o salrio, poderamos criar uma viso que s permitisse o acesso ao somatrio dos salrios: create view visao4 as select coluna1, sum(coluna2), coluna3 from tabela1; Podemos, tambm, usar uma viso para selecionar dados de mais de uma tabela: create view visao5 (a, b, c, d, e) as select tabela1.*, tabela2.coluna4, tabela2.coluna5 from tabela1, tabela2 where tabela1.coluna1 = tabela2.coluna1;

9 Estudo de caso (parte 3) Modelo fsico de dados

Na fase de modelagem fsica que o banco de dados descrito no modelo lgico de dados ser criado. A forma de descrever os arquivos que comporo o banco de dados depende do SGBD usado. Por este motivo usaremos a SQL para criar as tabelas. Fica a cargo do leitor a adaptao para o SGBD especfico que for utilizar. Para facilitar, repetiremos aqui a apresentao das tabelas definidas no tpico Estudo de caso (parte 2) Modelo lgico de dados e apresentaremos em seguida os comandos SQL para a criao das tabelas: Fornecedores Produtos Unid_Med Clientes *cd_fornecedor nome_fornecedor *cd_produto desc_produto cd_unid_med qt_estoque preco_unit Fig. 9.1: Tabelas fornecedores, produtos, unid_med e clientes. *cd_unid_med desc_unid_med *cd_cliente nome_cliente

Banco de Dados

64.68

Pedidos_ Fornecimento *nped_fornecedor cd_fornecedor dt_entrega situao

Pedidos_ Clientes *nped_cliente cd_cliente dt_pedido forma_pagamento situao

Vendedores *cd_vendedor nome_vendedor

Notas_ Fiscais *nnfiscal nped_cliente dt_emissao

cd_vendedor Fig. 9.2: Tabelas pedidos_fornecimento, pedidos_clientes, vendedores e notas_fiscais. Cotacoes_ Produtos *cd_fornecedor *cd_produto preco_oferecido Itens_Pedido_ Fornecimento *nped_fornecedor *cd_produto preco_unit Itens_Pedido_ Cliente *nped_cliente *cd_produto qt_comprada Itens_Nota_ Fiscal *nnfiscal *cd_produto nped_cliente

qt_pedida preco_unit Fig. 9.3: Tabelas cotacoes_produto, itens_pedido_fornecimento, itens_pedidos_clientes e itens_nota_fiscal. create table fornecedores ( cd_fornecedor char(5) unique not null, nome_fornecedor char(30) not null ); create table produtos ( cd_produto desc_produto cd_unid_medida qt_estoque preco_unit create table unid_med ( cd_unid_med desc_unid_med create table clientes ( cd_cliente nome_cliente char(5) unique not null, char(30) not null, char(5) not null, numeric not null, float not null ); char(5) unique not null, char(30) not null ); char(5) unique not null, char(30) not null );

create table pedidos_fornecimento ( nped_fornecedor char(5) unique not null, cd_fornecedor char(5) not null, dt_entrega char(8) not null, situacao char(1) not null );

Banco de Dados

65.68

create table itens_pedido_fornecimento ( nped_fornecedor char(5) not null, cd_produto char(5) not null, preco_unit float not null, qt_pedida numeric not null ); create table pedidos_cliente ( nped_cliente char(5) unique not null, cd_cliente char(5) not null, dt_pedido char(8) not null, forma_pagamento char(2) not null, situacao char(1) not null, cd_vendedor char(4) not null ); create table itens_pedidos_clientes ( nped_cliente char(5) not null, cd_produto char(5) not null, qt_comprada numeric not null, preco_unit float not null ); create table vendedores ( cd_vendedor char(4) unique not null, nome_vendedor char(30) not null ); create table notas_fiscais ( nnfiscal char(6) unique not null, nped_cliente char(5) not null, dt_emissao char(8) not null ); create table itens_nota_fiscal ( nnfiscal char(6) not null, cd_produto char(5) not null, nped_cliente char(5) not null ); create table cotacoes_produto ( cd_fornecedor char(5) not null, cd_produto char(5) not null, preco_oferecido float not null ); Na tabela produtos temos as colunas cd_produto, desc_produto, cd_unid_med, qt_estoque e preco_unit. Mas, na interao com o usurio ou na elaborao de relatrios, podemos necessitar tambm da descrio da unidade de medida alm do cdigo da unidade de medida. Em vez de deixar para as aplicaes juntar as tabelas produtos e unid_med, poderamos criar uma viso: create view vprodutos as select produtos.*, unid_med.desc_unid_med from produtos, unid_med where produtos.cd_unid_med = unid_med.cd_unid_med; Da mesma forma, poderamos criar uma viso para acessar o nome do fornecedor, juntamente com o seu cdigo, ao acessar a tabela pedidos_fornecimento:

Banco de Dados

66.68

create view vpedidos_fornecimento as select pedidos_fornecimento.*, fornecedores.nome_fornecedor from pedidos_fornecimento, fornecedores where pedidos_fornecimento.cd_fornecedor = fornecedores.cd_fornecedor; Outras vises poderiam ser criadas para atender outras necessidades.

10 Bancos

de dados cliente/servidor

distribudos

arquitetura

A tecnologia de banco de dados comeou a ser desenvolvida na poca dos computadores de grande porte que, normalmente, trabalhavam de forma isolada. Assim, o gerenciador do banco de dados, os dados e as aplicaes que acessavam o banco de dados residiam todos no mesmo computador e no havia acesso interativo ao banco (no havia sequer terminais ligados ao computador). Com a evoluo surgiram os terminais e as aplicaes interativas: o gerenciador, os dados e as aplicaes residindo no computador central e os usurios acessando as aplicaes via terminal. Mais adiante os computadores comearam a ser ligados em rede e comeou uma discusso: o sistema deve continuar centralizado, descentralizando apenas os pontos de acesso?

10.1 Bancos de dados distribudos

A arquitetura centralizada estava bem consolidada, mas o trfego de dados sobrecarregava desnecessariamente as redes de comunicao. Por exemplo, em uma aplicao bancria, a maior parte do acesso conta de um cliente ocorria na prpria agncia em que o cliente tinha conta (ainda no havia a flexibilidade atual de efetuar transaes a partir de qualquer agncia). Eventualmente que os dados dos clientes precisavam ser reunidos em um nico local e, assim mesmo de forma consolidada: apenas o saldo de cada conta e/ou o total de crditos e dbitos, no interessando o detalhamento de cada lanamento. Uma alternativa para a centralizao que imperava era o banco de dados distribudo. Nesta arquitetura cada computador tem uma cpia do gerenciador do banco de dados e uma parte dos dados. H comunicao entre as cpias do gerenciador, permitindo que um usurio ligado a um computador acesse os dados residentes em outro computador. Para melhorar a eficincia do sistema, muitas vezes parte dos dados duplicada (o mesmo conjunto de dados em mais de um computador), trazendo problemas adicionais de sincronizao na hora das atualizaes dos dados. Isso faz com que a complexidade do gerenciador aumente muito, tornando-o mais propenso s falhas.

10.2 Arquitetura cliente/servidor

Com o advento da micro-informtica e das redes interligando os microcomputadores, o usurio passou a dispor no apenas de um terminal burro, mas de um computador com razovel capacidade de processamento. Surgiu, ento, a arquitetura cliente/servidor, em que o gerenciador e o banco de dados residem em um computador central (geralmente um micro-computador com Banco de Dados 67.68

grande capacidade de armazenamento e de processamento) e a aplicao propriamente dita reside no micro-computador do usurio. Nessa arquitetura todo o processamento da aplicao, incluindo a parte de interface com o usurio, fica no computador do usurio (cliente), liberando o computador central (servidor), que fica responsvel apenas pelo gerenciamento dos dados, fornecendo-os de acordo com a demanda dos clientes. A denominao cliente/servidor se deve ao fato do computador cliente solicitar e receber servios de dados do computador servidor. Como o controle do acesso aos dados fica centralizado no servidor, este tende a ser menos complexo do que no caso do banco de dados distribudo. A arquitetura cliente/servidor pode ser implementada em duas camadas (como foi descrito acima) ou trs camadas. Na implementao em trs camadas introduzido um terceiro computador que fica localizado entre o cliente e o servidor. O computador onde reside o banco de dados passa a se chamar servidor de banco de dados e esse terceiro computador denominado servidor de aplicao. A aplicao fica dividida entre o cliente, que passa a ser responsvel apenas pela interface com o usurio da aplicao e o servidor de aplicao, responsvel pela comunicao com o servidor de banco de dados e com o cliente e, tambm, pelo processamento da aplicao. *** continuar sdfgdffds

Bibliografia
1) Tanembaum, Andrew S. Sistemas Operacionais Modernos. Rio de Janeiro. LTC. 1992. 2) Teixeira, Jos Helvcio et al. Do Mainframe para a Computao Distribuda Simplificando a Transio. Rio de Janeiro. Infobook, 1996. 3) Machado, Francis B., Maia, Luiz Paulo. Arquitetura de Sistemas Operacionais, 3 ed. Rio de Janeiro. LTC, 2002. 4) Silberschatz, Abraham, Gavin, Peter, Gagne, Greg. Sistemas Operacionais. Rio de Janeiro. Ed. Campus, 2000. 5) Tanembaum, Andrew S. Sistemas Operacionais Modernos, 2 ed. Rio de Janeiro. LTC, 2003.

Banco de Dados

68.68