Introdução a Banco de Dados

Disciplina: MODELAGEM DE BANCO DE DADOS Introdução a Banco de Dados 1. Introdução Um Sistema Gerenciador de Banco de Dados (SGBD) é constituído por um conjunto de dados associados a um conjunto de programas para acesso a esses dados. O principal objetivo de um SGBD é proporcionar um ambiente tanto conveniente quanto a eficiente para a recuperação e armazenamento das informações do banco de dados. Sistemas de banco de dados são projetados para gerir grandes volumes de informações. O gerenciamento de informações implica a definição das estruturas de armazenamento das informações e da definição dos mecanismos para a manipulação dessas informações. Também um sistema de banco de dados deve garantir a segurança das informações armazenadas contra eventuais problemas com o sistema, além de impedir tentativas de acesso não autorizadas. Também se os dados são compartilhados por diversos usuários o sistema deve evitar a ocorrência de resultados anômalos. 2. Por que Sistemas de Banco de Dados

Um Sistema de processamento de arquivos convencional onde, registros permanentes são armazenados em vários arquivos e diversos programas de aplicação são escritos para extrair e gravar registros nos arquivos apropriados, podem ser apropriadamente gerenciados pelos sistemas operacionais existentes. Mas, estes sistemas apresentam numerosas desvantagens: Inconsistência e Redundância de Dados: Como arquivos e programas normalmente são criados e mantidos por diferentes programadores, em geral é comum que os arquivos possuam formatos diferentes e os programas estejam escritos em diferentes linguagens de programação. Além disso, a mesma informação pode estar repetida em mais de um arquivo. Dificuldade de Acesso aos Dados: Normalmente em um sistema de processamento de arquivos comum, quando existe uma necessidade de uma relação de empregados, por exemplo, segundo uma determinada condição, se esta situação não tiver sido prevista inicialmente no sistema, é necessário que um novo programa seja desenvolvido e que gere esta lista solicitada. O fato é que este ambiente não está preparado para atender as necessidades de recuperação de informações de modo eficiente. Isolamento dos Dados: Como os dados estão dispersos em vários arquivos, e estes arquivos podem apresentar diferentes formatos, é difícil escrever novas aplicações para a recuperação apropriada destes dados. Problemas com Integridade: Os valores dos dados atribuídos e armazenados em um banco de dados devem

satisfazer certas restrições para manutenção da consistência. O problema aumenta quando as restrições atingem diversos itens de dados em diferentes arquivos. Problemas de atomicidade: Um sistema computacional está sujeito a falhas. E imprescindível garantir que, uma vez detectada uma falha, os dados sejam salvos em seu último estado consistente, anterior a ela. Por exemplo, uma operação de transferência bancária entre contas correntes, deve ser uma operação atômica, ou seja, deve ocorrer por completo, ou não ocorrer. Anomalias no acesso concorrente: Muitos sistemas permitem atualizações simultâneas dos dados para aumento do desempenho do sistema como um todo e para melhores tempos de resposta. Este tipo de interação pode resultar em inconsistência de dados. Por exemplo, dois saques simultâneos a uma mesma conta corrente. Problemas de Segurança: Nem todos os usuários de banco de dados estão autorizados ao acesso a todos os dados. Em um sistema bancário, por exemplo, os funcionários do departamento de pessoal não deveriam ter acesso a informações dos clientes do banco, só apenas ao conjunto de pessoas ao qual o seu departamento lhe diz respeito. Estas e outras dificuldades provocaram o desenvolvimentos dos SGBDs. Iniciaremos o estudo dos sistemas de bancos de dados, mostrando, para isso, conceitos e algoritmos que foram desenvolvidos para a efetiva manipulação dos mesmos.

Linguagens de Banco de Dados e Tipos de Usuários 1. Linguagens de Banco de Dados Um sistema de banco de dados proporciona dois tipos de linguagens: uma específica para os esquemas do banco de dados e outra para expressar consultas e atualizações. 1.2 Linguagens de Definição de Dados Um esquema de banco de dados é especificado por um conjunto de definições expressas por uma linguagem especial chamada linguagem de definição de dados (data-definition language - DDL). O resultado da compilação dos parâmetros DDLs é armazenado em um conjunto de tabelas que constituem um arquivo especial chamado dicionário de dados ou diretório de dados. Um dicionário de dados é um arquivo de metadados, isto é, dados a respeito de dados. A estrutura de memória e o método de acesso usados pelo banco de dados são especificados por um conjunto de definições em um tipo especial de DDL chamado de linguagem de definição e armazenamento de dados (data storage and definition language). 1.3 Linguagens Manipulação de Dados

Os níveis de abstração que foram discutidos anteriormente não se aplicam apenas à definição ou a èstrutura dos dados, mas também à sua manipulação. Por manipulação de dados, entendese: A recuperação das informações armazenadas no banco de dados. Inserção de novas informações no banco de dados. A remoção de informações do banco de dados. A modificação das informações do banco de dados. A linguagem de manipulação de dados (DML) é a linguagem que viabiliza o acesso ou a manipulação dos dados de forma compatível ao modelo de dados apropriado. São basicamente dois tipos: DMLs procedurais exigem que o usuário especifique quais dados são necessários, e como obtê-los. DMLs não-procedurais exige que o usuário especifique quais dados são necessários sem especificar como obtê-los. Uma consulta é uma solicitação para a recuperação de informações. A parte de uma DML que é responsável pela recuperação de informações é chamada linguagem de consultas (query language). 1.4 Gerenciamento de Transações Muitas vezes diversas operações em um banco de dados constituem de uma única unidade lógica de trabalho. Como o caso da transferência de créditos entre duas contas-correntes. A transferência deve acontecer como um todo ou nada deve ser

feito. Essa característica de tudo ou nada, é chamado de atomicidade. Além disso, é necessário que a transferência de fundos preserve a consistência do banco de dados. Essa exigência é chamada de consistência. Depois da execução com sucesso da operação de transferência, os novos valores devem persistir, a despeito da possibilidade de falhas no sistema. Essa persistência é chamada de durabilidade. Uma transação é uma coleção de operações que desempenha uma função lógica única dentro de uma aplicação do sistema de banco de dados. Cada transação é uma unidade de atomicidade e consistência. Assim, exige-se que as transações não violem nenhuma regra de consistência do banco de dados. É de responsabilidade do programador definir as diversas transações tais que cada uma preserve a consistência do banco de dados. É de responsabilidade do sistema de banco de dados assegurar as propriedades de atomicidade e durabilidade no gerenciamento das transações. É de sua responsabilidade também detectar falhas e recuperar o banco de dados garantindo o retorno de seu último estado consistente. Outra responsabilidade importante diz respeito ao controle de concorrência, que consiste de controlar a interação entre transações concorrentes de modo a garantir a consistência do banco de dados. 1.5 Administração de Memória

Os bancos de dados, normalmente, ocupam um grande volume de memória. Este tamanho muitas vezes pode chegar não só a gigabytes, mas também a terabytes. Um gerenciador de memória é um módulo de programas para interface entre o armazenamento de dados em um nível baixo e consultas e programas submetidos ao sistema. O gerenciador de memória é responsável pelo armazenamento, recuperação e atualização de dados no banco de dados. 1.6 Administrador de Banco de Dados Uma das grandes motivações de uso de SGBDs é o controle centralizado tanto de dados quanto dos programas de acesso a esses dados. A pessoa que centraliza esse controle do sistema é chamada de administrador de banco de dados (DBA). Dentre as suas funções, destacam-se: Definição do esquema. O DBA cria o esquema do banco de dados original escrevendo um conjunto de definições que são transformadas pelo compilador DDL em um conjunto de tabelas armazenadas de modo permanente no dicionário de dados. Definição da estrutura de dados e métodos de acesso. O DBA cria estruturas de dados e métodos de acesso apropriados escrevendo um conjunto e definições, as quais são traduzidas pelo compilador de armazenamento de dados e pelo compilador de linguagem de definição de dados. Esquema e modificações na organização física. Os programadores realizam relativamente poucas alterações no esquema do banco de dados ou na descrição da organização física de armazenamento.

Fornecer autorização de acesso ao sistema. O fornecimento de diferentes tipos de autorização no acesso aos dados permite que o administrador de dados regule o acesso dos diversos usuários às diferentes partes do sistema. Especificação de regras de integridade. Os valores dos dados armazenados no banco de dados devem satisfazer certas restrições para manutenção de sua integridade. 1.7 Usuários de Banco de Dados Há quatro tipos básicos de usuários de sistemas de banco de dados, cuja diferença refere-se a suas expectativas de interação com o sistema. Programadores de aplicações. São profissionais em computação que interagem com o sistema por meio das chamadas DML, as quais são envolvidas por programas escritos na linguagem hospedeira. Estes programas são comumente referidos como programas de aplicação. Usuários sofisticados. Interagem com o sistema sem escrever programas. Formulam suas solicitações ao banco de dados por meio de linguagens de consultas. Cada uma dessas solicitações é submetida ao processador de consultas. Usuários especialistas. São usuários sofisticados que escrevem aplicações especializadas de bancos de dados que não podem ser classificadas como aplicações tradicionais em processamento de dados.

Usuários navegantes. São os usuários comuns que interagem com o sistema chamando um dos programas aplicativos permanentes já escritos, como por exemplo, um usuário que pede a transferência de uma conta para outra.

Considerações Básicas, Abstração e Modelos de Dados Bancos de Dados e Sistemas de Banco de Dados têm se tornado um componente essencial todos os dias da vida moderna. Aplicações de banco de dados tradicionais dizem respeito a sistemas bancários, sistemas de reservas aéreas, sistemas de controle de estoque. Com o avanço da tecnologia, novos tipos de bancos de dados foram desenvolvidos, com aplicações e uso específicos. Bancos de Dados Multimídia podem, por exemplo, armazenar figuras, vídeoclips e mensagens de sons. Bancos de Dados Geográficos podem armazenar e analisar mapas, dados climáticos e imagens de satélite. DataWarehouses e Processamentos Analítico On-line (OLAP) são sistemas usados em muitas empresas para extrair e analisar informações úteis de sistemas de banco de dados muito grandes para a tomada de decisões. Tecnologias de Tempo Real e de Banco de Dados Ativos são usados no controle industrial e em processo de manufatura. Técnicas de busca em bancos de dados, com aplicações na Web, têm melhorado a eficiência dos mesmos. No entanto, temos que entender o básico das aplicações de banco de dados tradicionais. Um banco de dados pode ser considerado como uma coleção de dados relacionados. Por dado entendem-se fatos conhecidos que podem ser armazenados e que possuem um significado implícito. Um banco de dados possui as seguintes propriedades implícitas:

Representa alguns aspectos do mundo real, muitas vezes chamado de mini-mundo ou universo do discurso. É uma coleção de dados logicamente coerente com alguns significados inerentes aos mesmos. É projetado, construído e povoado com dados para um propósito específico. Um banco de dados pode ser de qualquer tamanho e de complexidade variada. Pode ser gerado e mantido manualmente ou pode ser computadorizado. Um Sistema de Gerenciamento de Banco de Dados é uma coleção de programas que permitem que usuários criem e mantenham um banco de dados. Um SGBD é também um sistema de software de propósito geral que facilita o processo de definição, construção e manipulação de banco de dados para várias aplicações. A definição de um banco de dados envolve especificação de tipos de dados, estruturas e restrições para que os dados possam ser armazenados no banco de dados. A construção do banco de dados é o processo de armazenamento de dados em algum armazenamento médio que é controlado pelo SGBD. A manipulação do banco de dados inclui tais funções como consulta a banco de dados para recuperar dados específicos e a atualização destes dados. Chamaremos de Sistema de Banco de Dados, o banco de dados e o SGBD, juntos. A Figura 1 mostra a estrutura de um Sistema de Banco de Dados.

Figura 1 Um Ambiente de Sistema de Banco de Dados 3. Abstração de Dados Um SGBD, como já dissemos, é uma coleção arquivos e programas inter-relacionados que permitem ao usuário o acesso para consultas e alterações a esses dados. Um dos grandes benefícios de um sistema de banco de dados é permitir aos usuários, uma visão abstrata dos dados.

Um sistema precisa ser eficiente na recuperação de informações. Esta eficiência muitas vezes está relacionada com a complexidade internas das estruturas de representação destes dados. Esta complexidade precisa ser transparente para os usuários, ou seja, através dos níveis de abstração, os SGBDs omitem a complexidade de armazenamento e manutenção dos dados que estão sendo manipulados, de modo a facilitar a interação dos usuários com o sistema. Nível Físico: é o nível de abstração mais baixo e descreve como os dados estão de fato armazenados. Nível Lógico: este é o nível de abstração médio, que descreve quais dados estão armazenados no banco de dados e quais são os inter-relacionamentos entre eles. O nível lógico é normalmente usado pelos administradores que precisam decidir quais as informações que precisam estar no banco de dados. Nível de Visão: Este nível de abstração mais alto que descreve apenas parte do banco de dados. Muitos usuários dos bancos de dados nem precisam conhecer todas as informações armazenadas. Para isso, níveis de visão são definidos de modo que as interações sejam simplificadas. A figura abaixo mostra o inter-relacionamento entre estes três níveis de abstração:

Figura 2 Três níveis de Abstração de dados Podemos fazer uma analogia dos níveis de abstração com tipos de dados em linguagens de programação. Por exemplo, dada a estrutura abaixo: Type cliente = record Nome_cliente : string; Seguro_social : string; Rua_cliente : string; Cidade_cliente : string; end; No nível físico, um registro de cliente pode ser escrito como um bloco consecutivo de memória. No nível lógico, cada registro é descrito por um tipo definido, como ilustrado no segmento de

código acima. Normalmente os programadores e administradores do banco de dados trabalham neste nível de abstração. No nível de visão, os usuários vêem apenas um conjunto de programas de aplicação que escondem os detalhes dos tipos de dados. 3.1 Instâncias e Esquemas Um banco de dados muda ao longo do tempo por meio das informações que nele são inseridas ou excluídas. O conjunto de informações contidas em determinado banco de dados em um dado momento é chamado instância do banco de dados. O projeto geral do banco de dados é chamado de esquema. Fazendo uma análise comparativa com o exemplo dado de clientes, acima, uma variável poderia ser declarada como: Var cliente1 : cliente; A definição de tipo em uma linguagem de programação corresponde ao esquema do banco de dados. O valor em um dado instante de uma variável de um determinado tipo, corresponde a uma instância do esquema do banco de dados. Os sistemas de banco de dados apresentam diversos esquemas, referentes aos níveis de abstração que foram discutidos. Em geral os sistemas de banco de dados são suporte a um esquema físico, um esquema lógico e vários subesquemas.

A capacidade de modificar a definição dos esquemas em determinado nível, sem afetar o esquema do nível superior, é chamado independência de dados. Existem dois níveis de independência de dados: a. Independência física de dados b. Independência lógica de dados 4. Modelos de Dados Um modelo de dados é um conjunto de ferramentas conceituais utilizadas para a descrição de dados, relacionamento entre esses dados, semântica de dados e regras de consistência. Os modelos são classificados em três diferentes grupos: modelos lógicos com base em objetos, modelos lógicos com base em registros e modelos físicos. 4.1 Modelos Lógicos com base em Objetos Os modelos lógicos com base em objetos são usados na descrição de dados no nível lógico e de visões. Existem vários modelos desta categoria, tais como: Modelo Entidade-Relacionamento Modelo Orientado a Objetos Modelo Semântico de Dados Modelo Funcional de Dados

4.1.1 Modelo Entidade-Relacionamento O modelo de dados entidade-relacionamento (E-R) tem como base a percepção do mundo real como um conjunto de objetos básicos, chamados de entidades, e do relacionamento entre eles. Uma entidade é uma coisa ou um objeto do mundo real, que pode ser identificado por outros objetos. As entidades são descritas no banco de dados por meio de seus atributos. Um relacionamento é uma associação entre entidades. Além das entidades e dos relacionamentos, o modelo E-R representa certas regras as quais o conteúdo do banco de dados precisa respeitar. 4.1.2 Modelo Orientado a Objetos O modelo orientado a objetos, assim como o E-R, tem por base um conjunto de objetos. Um objeto contém valores armazenados em variáveis instâncias dentro do objeto. Um objeto também contém conjuntos de códigos que operam este objeto. Estes conjuntos de códigos são chamados de métodos. Os objetos que contém os mesmos tipos de valores e os mesmos métodos são agrupados em classes. Onde uma classe pode ser vista como uma definição de tipo para objetos. 4.2 Modelos Lógicos Baseados em Registros Modelos lógicos baseados em registros são usados para descrever os dados no nível lógico e de visão. É usado tanto para especificar a estrutura lógica do banco de dados quanto para

implementar uma descrição de alto nível. Dos três modelos apresentados, o modelo relacional é o que mais tem se destacado nos últimos anos. O modelo hierárquico e de rede é ainda usado em um grande número de banco de dados antigos. 4.2.1 Modelo Relacional O modelo relacional usa um conjunto de tabelas para representar tanto os dados como a relação entre eles. Cada tabela possui múltiplas colunas e cada uma possui um único nome. 4.2.2 Modelo de Rede O modelo de rede representa os dados por um conjunto de registros e as relações entre esses registros são representadas por links, as quais podem ser vistas pelos ponteiros. Os registros são organizados no banco de dados por um conjunto arbitrário de gráficos. 4.2.3 Modelo Hierárquico O modelo hierárquico é similar ao modelo de rede pois os dados e suas relações são representados também por registros e links. A diferença é que no modelo hierárquico os registros estão organizados em árvores ao invés de gráficos arbitrários. 4.3 Modelos Físicos de Dados

Os modelos físicos de dados são usados para descrevê-los no nível mais baixo. Há poucos modelos físicos de dados em uso. Dois deles são conhecidos: o modelo unificado, e o modelo de partição de memória.

Modelo Entidade-Relacionamento 1. Conceitos básicos O modelo Entidade-Relacionamento (E-R) tem por base a percepção de que o mundo real é formado por um conjunto de objetos chamados de entidades e pelo conjunto de relacionamentos entre esses objetos. Foi desenvolvido para facilitar o projeto do banco de dados, permitindo a especificação do esquema da empresa que representa toda a estrutura lógica. O modelo E-R é um dos modelos com maior capacidade semântica; que se referem a tenativa de representar o significado dos dados. Existem três noções básicas empregadas pelo modelo E-R: conjunto de entidades, conjunto de relacionamentos, e os atributos. 1.1. Conjunto de Entidades Uma entidade é uma coisa ou um objeto do mundo real que pode ser identificada de forma unívoca em relação a todos os outros objetos. Por exemplo, cada pessoa na empresa é uma entidade. Uma entidade tem um conjunto de propriedades, e os valores para alguns conjuntos dessas propriedades devem ser únicos. Uma entidade pode ser concreta como uma pessoa ou um livro, ou pode ser abstrata como um empréstimo, uma viagem de férias ou um conceito.

Um conjunto de entidades é um conjunto de abrange entidades de um mesmo tipo que compartilham as mesmas propriedades: os atributos. As entidades individuais que constituem um conjunto são chamadas de extensões do conjunto de entidades. Uma entidade é representada por um conjunto de atributos. Atributos são propriedades descritivas de cada membro de um conjunto de entidades. Formalmente um atributo de um conjunto de entidades é uma função que relaciona o conjunto de entidades a seu domínio. Um atributo, como é usado no modelo E-R, pode ser caracterizado pelos seguintes tipos: Atributos Simples ou compostos. Os atributos simples são aqueles que não são divididos em partes. Os compostos podem ser divididos em partes, por exemplo, nome_cliente, pode ser estruturado em prenome, nome_intermediário, e sobrenome. Os atributos compostos ajudam-nos a agrupar atributos correlacionados tornando o modelo mais claro. Atributos monovalorados ou multivalorados. Um exemplo de um atributo monovalorado poderia ser o atributo número_empréstimo, o qual teria associado apenas um número de empréstimo. Pode acontecer, no entanto, que uma determinada instância possua um conjunto de valores para uma única entidade. Por exemplo, o atributo nome_dependente, da entidade empregado, pode ter um, nenhum ou vários dependentes cadastrados. Atributos nulos. Um atributo é nulo quando uma entidade não apresenta valor para o mesmo. Por exemplo, se um empregado não possui dependentes o valor do atributo

nome_dependente será nulo, significando que este atributo não é aplicável a esta instância em particular. Atributo derivado. O valor deste atributo pode ser derivado de outros atributos ou entidades a ele relacionados. Por exemplo, a idade de um funcionário pode ser calculada pela data de seu aniversário. 2. Conjunto de Relacionamentos Um relacionamento é uma associação entre uma ou várias entidades. Um conjunto de relacionamentos é um conjunto formado por relacionamentos de um mesmo tipo. Considere dois relacionamentos de entidades cliente e empréstimo. O conjunto de relacionamentos devedor denota a associação entre clientes e empréstimos bancários contraídos pelo cliente. A associação entre os conjuntos de entidades é referida como uma participação, isto é, o conjunto de entidades E 1, E 2,..., E n participa do conjunto de relacionamentos R. A função que uma entidade desempenha em um relacionamento é chamada papel. Uma vez que os conjuntos de entidades participantes em um conjunto de relacionamentos são geralmente distintos, papéis são implícitos, e não são em geral, especificados. Mas, são úteis quando o relacionamento precisa ser esclarecido. Em conjuntos de relacionamentos recursivos, nomes explícitos de papéis muitas vezes são necessários. Por exemplo, o conjunto de entidades empregado, e o conjunto de

relacionamentos trabalha_para, que é modelado para ordenar os pares da entidade empregado. O primeiro empregado tem papel de gerente, enquanto que o outro tem o papel de empregado. Um relacionamento pode ter atributos descritivos. O conjunto de relacionamentos depositante, com o conjunto de entidades cliente e conta, por exemplo, apresenta o atributo data_acesso. Relacionamento binário é um relacionamento que envolve dois conjuntos de entidades. A maior parte dos conjuntos de relacionamentos modelados em um sistema de banco de dados é do tipo binário. Algumas vezes, no entanto, aparecem relacionamentos que envolvem mais de dois conjuntos de entidades. Como exemplo, podemos combinar os conjuntos de relacionamentos devedor e agência_empréstimo formando o conjunto de relacionamentos CEA, entre as entidades Cliente, Empréstimo e Agência. O número de entidades que participam de um relacionamento define o grau deste relacionamento. Um conjunto de relacionamento binário tem grau 2, e um ternário, grau 3. Conjunto de Entidades ou Atributos? Muitas vezes aparecem dificuldades no reconhecimento do que seja uma entidade ou um atributo. Por exemplo, uma entidade empregado com dois atributos: nome_empregado, e telefone. O atributo telefone pode ser modelado como uma entidade. Se definirmos como atributo, isto implica dizer que cada empregado tem precisamente um número de telefone a ele associado. Caso seja modelado como entidade, reflete que um

empregado pode ter vários (ou nenhum) números de telefones a ele associado. Já o atributo nome_empregado não poderia nunca ser modelado como entidade. Infelizmente não existe uma resposta simples para sabermos do que constitui um atributo e o que constitui uma entidade. As distinções vão depender da estrutura geral que está sendo modelada. Conjuntos de Entidades ou de Relacionamentos? Nem sempre fica claro se devemos modelar um objeto como um conjunto de entidades ou de relacionamentos. Por exemplo, considere o problema do empréstimo bancário representado como um relacionamento entre clientes e agências, com número_empréstimo e conta como atributos. Cada empréstimo é representado como um relacionamento entre um cliente e uma agência. Se todo empréstimo é tomado por exatamente um cliente e está associado à exatamente uma agência, podemos resolver o projeto de modo satisfatório, representando empréstimo como relacionamento. Mas, considere que vários clientes tomem um mesmo empréstimo em conjunto. Então, nesse caso, é necessário definir um relacionamento em separado para cada componente do empréstimo conjunto. Desta forma, os atributos descritivos numero_empréstimo e conta precisarão ser replicados para cada um dos relacionamentos. Os problemas que surgem devido a esta replicação são: (1) os dados são armazenados diversas vezes, desperdiçando espaço em

memória, e (2) as atualizações deixam potencialmente os dados em estado inconsistente. Ao descrever empréstimo como uma entidade, este problema de replicação desaparece. Relacionamentos n-ésimos. Uma outra característica importante que diz respeito a relacionamentos, é que sempre é possível recompor um conjunto de relacionamentos não-binário, por um número de relacionamentos binários distintos. Mas, pode ser necessária a criação de um atributo de identificação para o conjunto de entidades criado para substituir o conjunto de relacionamentos. Além disso, um conjunto de relacionamentos n-ésimo mostra claramente todos os conjuntos de entidades que participam de uma determinada relação. O projeto correspondente usando somente relacionamentos binários torna mais difícil estabelecer as restrições desta participação. 3. Mapeamento de Restrições 3.1 Cardinalidade O esquema E-R de uma empresa pode definir certas restrições as quais o conteúdo do banco de dados deve respeitar. Exemplos de restrições são: o mapeamento de cardinalidades e a existência de dependências. O mapeamento de cardinalidades expressa o número de entidades às quais outras entidades podem estar associadas através de um conjunto de relacionamentos. Para um conjunto de relacionamentos binário, o mapeamento de cardinalidades segue as instruções abaixo:

Um para um. Uma entidade em A está associada no máximo a uma entidade em B, e uma entidade em B está associada no máximo a uma entidade em A. Um para muitos. Uma entidade em A está associada a várias entidades em B. Uma entidade em B deve estar associada a uma única entidade em A. Um para um. Muitos para um. Uma entidade em A está associada a no máximo uma entidade em B. Uma entidade em B, entretanto, pode estar associada a um número qualquer de entidades em A. Muitos para muitos. Uma entidade em A está associada a qualquer número de entidades em B e uma entidade em B está associada a um número qualquer de entidades em A.

Figura 2 Mpeamento de Cardinalidade. Muitos para Muitos. O mapeamento de cardinalidade para um conjunto de relacionamentos em particular é obviamente dependente das situações reais que estão sendo modeladas. O rateio de cardinalidades de um relacionamento pode afetar a colocação dos atributos nos relacionamentos. Conjuntos de relacionamentos um para um, ou um para muitos devem associar os atributos a uma das entidades participantes. Considere o caso das entidades cliente e conta, e o relacionamento depositante. O atributo dataacesso deverá estar associado à entidade conta. 3.2 Dependência de Existência

existência. Se a existência da entidade x depende da existência de y. E se y for excluído, o mesmo deve acontecer com x. A entidade y é chamada de entidade dominante e a x é chamada entidade subordinada. Como exemplo, considere o conjunto de entidades empréstimo e o conjunto de entidades pagamento. Toda entidade pagamento está associada a uma entidade empréstimo. Se uma entidade empréstimo é excluída, todas as entidades pagamento a ela associada devem ser excluídas também. Se por outro lado, uma entidade pagamento for excluída, a entidade empréstimo não será afetada. Portanto, a entidade empréstimo é dominante e a entidade pagamento subordinada. A participação de um conjunto de entidades E no conjunto de relacionamento R é dita total se todas as entidades em E participam de pelo menos um relacionamento em R. Se somente algumas entidades em E participam do relacionamento R a participação do conjunto de entidades é dito parcial. A participação total está relacionada à existência de dependência. 4. Chaves Precisamos especificar como as entidades dentro de um dado conjunto de entidades e os relacionamentos dentro de um conjunto de relacionamentos podem ser identificados. O conceito de chave nos ajuda a fazer esta distinção. 4.1 Conjunto de Entidades

Uma superchave é um conjunto de um ou mais atributos que, tomados coletivamente, nos permitem identificar de maneira unívoca, uma entidade em um conjunto de entidades. Ex. seguro_social, e a combinação de seguro_social com nome_cliente. Se K é uma superchave, então qualquer superconjunto de K é também uma superchave. Mas, queremos supoerchaves para as quais nenhuma subconjunto possa ser uma superchave. Essas superchaves são chamadas de chaves candidatas. O termo chave primária é o termon usado para caracterizar a chave candidata escolhida pelo projetista do banco como sendo de significado especial para a identificação das entidades. A especificação de uma chave representa uma restrição ao mundo real da empresa que está sendo modelada. 4.2 Conjunto de Relacionamentos A chave primária de um conjunto de entidades permite-nos distinguir as várias entidades de um conjunto. Precisamos definir um mecanimo para a indetificação dos vários relacionamentos em um conjunto de relacionamentos. Seja R um conjunto de relacionamentos envolvendo os conjuntos de entidades E1, E2,..., Em. Seja uma chave_primária (Ei) denotando o conjunto de atributos que formam a chave primária do conjunto de entidades Ei. Se o relacionamento R não possui atributos, então o conjunto de atributos abaixo descreve um relacionamento individual do conjunto R: Chave_primária (E1) U Chave_primária (E2) U... U Chave_primária (En)

A estrutura da chave primária para o conjunto de relacionamentos depende do mapeamento da cardinalidade do mesmo. Se o relacionamento é muitos para muitos, a chave primária do relacionamento constitui a união das chaves primárias das duas entidades. Se o relacionamento é muitos para um, então a chave primária da entidade de menor cardinalidade pode identificar o relacionamento. Se o relacionamento é um para um, qualquer uma das chaves pode ser usada.

Modelo Relacional 1. Conceitos básicos Um banco de dados relacional é composto por um conjunto de tabelas ou relações, cada uma das quais com um nome único. A terminologia tabela é mais comum nos produtos comerciais e na prática. Já a terminologia relação foi utilizada na literatura original sobre a abordagem relacional e é mais comum na área acadêmica. 1.1 Tabelas Uma tabela é um conjunto não-ordenado de linhas (tuplas, na terminologia acadêmica), onde cada linha é composta por uma série de campos, ou atributos. Cada linha de uma tabela representa um relacionamento entre um conjunto de valores. Cada campo é identificado por nome do campo (ou atributo), e o conjunto de campos das linhas de uma tabela que possuem o mesmo nome formam uma coluna. Comparando-se a tabela de banco de dados com um arquivo convencional do sistema de arquivos de um computador, identificam-se as seguintes diferenças: As linhas de uma tabela não estão ordenadas. A ordem de recuperação pelo SGBD é arbitrária, a menos que a instrução de consulta tenha especificado uma ordenação. Não é possível referenciar linhas de uma tabela por posição. Os valores de campo de uma tabela são atômicos e monovalorados. Em arquivos convencionais campos podem

ser compostos por outros campos, e podem ser multivalorados. As linguagens de consulta a bases de dados relacionais permitem o acesso por quaisquer critérios envolvendo os campos de uma ou mais linhas. Em arquivos convencionais, para buscar registros com base em valores de seus campos é necessário que exista um caminho de acesso determinado, que é uma estrutura auxiliar como o índice ou uma cadeia de ponteiros. 1.2 Chaves O conceito básico para estabelecer relações entre linhas de tabelas de um banco de dados relacional é o da chave. Em um banco de dados relacional há pelo menos três tipos de chaves a considerar: a chave primária, a chave alternativa e a chave estrangeira. 1.2.1 Chave primária Uma chave primária é uma coluna ou uma combinação de colunas que identificam uma linha das demais dentro de uma tabela. Na tabela de Empregados abaixo, a chave primária é a coluna CódigoEmp. CódigoEmp Nome CódigoDepto CategFuncional E5 Souza D1 C5 E3 Santos D2 C5 E2 Silva D1 C2 E1 Soares D1 - Tabela 1 - Empregados

A tabela abaixo mostra uma tabela de Dependentes que possui uma chave primária composta: CódigoEmp e NoDep. CódigoEmp NoDep Nome Tipo DataNasc E1 01 João Filho 12/12/91 E1 02 Maria Esposa 01/01/50 E2 01 Ana Esposa 05/11/55 E6 01 Paula Esposa 04/07/60 E6 02 José Filho 03/02/85 Tabela 2 - Dependentes Nas definições formais de chave primária, exige-se que a mesma seja mínima, ou seja, todas as suas colunas são efetivamente necessárias para garantir o requisito de unicidade de valores da chave. Na abordagem relacional, ao se definir uma chave primária, não está se definindo um caminho de acesso. Está se definindo uma restrição de integridade que precisa ser obedecida para todos os estados válidos do BD. Neste caso, a regra é a da unicidade dos valores nas colunas que compõem a chave. 1.2.2 Chave estrangeira Uma chave estrangeira é uma coluna ou uma combinação de colunas cujos valores aparecem necessariamente como chave primária de uma tabela. A chave estrangeira é o mecanismo pelo qual implementam-se os relacionamentos em um banco de dados relacional. Seja a seguinte tabela de departamentos abaixo:

CódigoDepto D1 D2 D3 NomeDepto Compras Engenharia Vendas Tabela 3 Departamentos Na tabela de Empregados, identificada neste exemplo como Tabela 1, a coluna CódigoDepto é uma chave estrangeira em relação a chave primária da tabela Departamentos, ou tabela 3. Isso significa que, na tabela Empregados, não podem aparecer linhas que contenham um valor do campo CódigoDepto que não exista na coluna do mesmo nome da tabela Departamentos. Interpretando esta restrição, dizemos que todo empregado deve estar associado a um departamento. A inclusão de uma chave estrangeira impõe restrições que devem ser garantidas em diversas situações de alteração do banco de dados: Quando da inclusão de uma linha na tabela que contém a chave estrangeira. Quando da alteração do valor da chave estrangeira. Quando da exclusão de uma linha na tabela que contém a chave primária referenciada como chave estrangeira. A palavra estrangeira pode denotar a idéia enganosa de que a mesma sempre referencia uma chave primária de uma outra tabela. Entretanto esta restrição não existe, A chave

estrangeira pode referenciar a chave primária da própria tabela. Por exemplo, na tabela Empregados mostrada na Tabela, pode existir um campo denotado CodigoEmpGerente que é o código de um outro empregado que é gerente do empregado da linha em questão. CódigoE mp Nome CódigoDep to CategFuncio nal CódigoEmpGere nte E5 Souza D1 C5 - E3 Santo D2 C5 E5 s E2 Silva D1 C2 E5 E1 Soare s D1 - E1 1.2.3 Chave alternativa Em alguns casos, mais de uma coluna ou combinações de colunas podem servir para distinguir uma linha das demais. Uma das colunas é escolhida como chave primária. As demais colunas são denominadas chaves alternativas. Na tabela de Empregados abaixo, tanto a coluna CodigoEmp quanto a coluna CIC podem ser usadas para distinguir uma linha das demais. Como o CodigoEmp foi o escolhido para ser

chave primária, dizemos que a coluna CIC é uma chave alternativa. CódigoEmp Nome CódigoDepto CategFuncional CIC E5 Souza D1 C5 132.121.331-20 E3 Santos D2 C5 891.221.111-11 E2 Silva D1 C2 341.511.775-45 E1 Soares D1-631.692.754-88 1.3 Domínios Quando uma tabela de banco de dados é definida, para cada coluna da tabela deve ser especificado um conjunto de valores que os campos da respectiva coluna podem assumir. Este conjunto de valores é chamado de domínio da coluna, ou domínio do campo. Além disso, deve ser especificado se os campos da coluna podem estar vazios ou não (null em inglês). Estar vazio indica que o campo não recebeu nenhum valor de seu domínio. As colunas na quais não são admitidos valores vazios são chamadas de colunas obrigatórias. As colunas nas quais podem aparecer campos vazios são chamadas de colunas opcionais. 1.4 Restrições de Integridade Um dos principais objetivos de Banco de Dados é manter a integridade dos dados. Dizer que os dados de um BD estão íntegros significa dizer que eles refletem corretamente a realidade representada pelo banco de dados e que são consistentes entre si. Para garantir a integridade dos dados o

SGBD oferece o mecanismo de restrições de integridade. Uma restrição de integridade é uma regra de consistência de dados que é garantida pelo próprio SGBD. Em SGBD Relacionais, existem as seguintes restrições de integridade conhecidas: Integridade de domínio: especificam que o valor de um campo deve obedecera definição de valores admitidos para a coluna ( o domínio da coluna). Integridade de vazio: é especificado se os campos de uma coluna podem ou não ser vazios. Campos que compõem a chave primária são sempre obrigatórios. Integridade de chave: trata-se da restrição que define que os valores da chave primária e alternativa devem ser únicos. Integridade referencial: define que os valores dos campos que aparecem em uma chave estrangeira devem aparecer na chave primária da tabela referenciada. Existem outros tipos de restrições de integridade que não se encaixam em nenhuma das categorias acima mencionadas e que normalmente não são garantidas pelo SGBD. Estas restrições são chamadas de restrições semânticas. Exemplos: Um empregado do departamento denominado Finanças não pode ter a categoria funcional Engenheiro.

Um empregado não pode ter um salário maior do que seu superior imediato.

Álgebra Relacional A álgebra relacional é uma linguagem de consultas procedural. Consiste em um conjunto de operações tendo como entrada uma ou duas relações e produzindo como resultado, uma nova relação. As operações fundamentais na álgebra relacional são: select, project, union, set difference, cartesian product e rename. Operações Fundamentais 1. Operação Select 2. Operação Project Suponha que desejamos listar todos os números de empréstimos e todos os totais correspondentes, sendo que o nome das agências envolvidas não interessa. A operação project permite-nos produzir esta relação. A operação project é primária, e retorna o argumento da relação deixando de lado certos atributos. Já que a relação é um conjunto, quaisquer linhas em duplicidade são eliminadas. A projeção é denotada pela letra grega pi. Listamos, subscritos em, os atributos que desejamos no resultado. O argumento da relação vem entre parênteses, a seguir. Uma consulta para relacionar todos os números de empréstimos e totais desses empréstimos pode ser escrita da seguinte forma: número_empréstimo, total (empréstimo) Relação resultante: Número_empréstimo Total

L-17 L-23 L-15 L-14 L-93 L-11 L-16 1000 2000 1500 1500 500 900 1300 3. Operação Relacional de Comparação Consideremos uma consulta mais complexa como encontre todos os clientes que moram em Olinda. A consulta seria: nome_cliente ( cidade_clliente= Olinda ) (Cliente)) Ao invés de dar o nome da relação como argumento da projeção, criamos uma expressão que evolui para uma relação. 4. Operação Union Considere a consulta para encontrar os nomes de todos os clientes do banco que tenham uma conta, um empréstimo, ou ambos. Note que a relação cliente não possui esta informação. Para responder esta pergunta, o banco precisa de informações da relação depositante, e da relaçãodevedor. Para encontrar todos os clientes com um empréstimo no banco: nome_cliente (devedor)

Para encontrar todos os clientes que possuem conta no banco: nome_cliente (depositante) Para responder a consulta precisamos da união desses dois conjuntos. Encontramos esses dados na relação binária união, denotada por. Logo, a expressão lógica completa da consulta é: nome_cliente (devedor) nome-cliente (depositante) Em geral precisamos que uniões sejam feitas entre relações compatíveis entre si. Por exemplo, não faria sentido tomar a união da relação empréstimo e da relação devedor. Para uma operação de união r s válida, são necessárias duas condições: 1. As relações r e s devem possuir o mesmo numero de atributos. 2. Os domínios do I-ésimo atributo de r e o I-ésimo atributo de s devem ser os mesmos para todo i. 5. Operação Diferença entre Conjuntos A operação diferença entre conjuntos denotada por -, permitenos encontrar as tuplas que estão numa relação, mas não em outra. A expressão r s resulta na relação que contém tuplas que estão em r mas não em s. Podemos encontrar todo os clientes que possuem conta no banco mas não contraíram empréstimos escrevendo: nome_cliente (depositante) - nome_cliente (devedor)

Assim como no caso da operação de união, precisamos assegurar que o conjunto diferença seja feito entre relações compatíveis. Portanto, para que as operações de diferença entre conjuntos r e s seja válida, precisamos que as relações r e s possuam o mesmo número de atributos e que o domínio do I-ésimo atributo de r e do I-ésimo atributo de s sejam os mesmos. 6. Operação Produto Cartesiano A operação Produto-Cartesiano representada por x, permite-nos combinar informações de duas relações quaisquer. Representamos o produto das relações r1 e r2 por r1 x r2. Uma relação é definida como um subconjunto de um produto cartesiano de um conjunto de domínios. Desde que um mesmo nome de atributo pode aparecer tanto em r1 como em r2, precisamos estabelecer um nome de esquema para diferenciar esses dois atributos. Para os atributos que aparecem apenas uma vez nos dois esquemas podemos omitir o nome da relação. O relação resultante do produto cartesiano de r = devedor x empréstimo, possui uma tupla para cada par de tuplas possível: um da relação devedor outro da relação empréstimo. Então, a relação resultante é uma relação grande. Assuma que podemos ter n1 tuplas em devedor, e n2 tuplas em empréstimo. A relação resultante possui n1 * n2 tuplas em r. Se quisermos, por exemplo, encontrar todos os nomes de todos os clientes que tenham um empréstimo na agência casa forte. Podemos precisar para isso, de informações das relações devedor e empréstimo. Então a expressão: nome_agência = casa forte (devedor x empréstimo)

nos dá como resultado uma relação dos devedores ligados a agência casa forte. Como a operação produto cartesiano associa todas as tuplas de empréstimo a todas as tuplas de devedor, sabemos que se um cliente contrai um empréstimo na agência Casa Forte então existe algumas tuplas em devedor X empréstimo que contém o seu nome. Se escrevermos, então: devedor.numero_empréstimo = empréstimo.número_empréstimo ( nome_agencia = casa forte (devedor x empréstimo)) E se quisermos apenas o nome do cliente, podemos fazer uma projeção: nome_cliente ( devedor.número_empréstimo = empréstimo.número_empréstimo ( nome_agência = casa forte (devedor x empréstimo) 7. Operação Rename Ao contrário das relações em um banco de dados, o resultado de uma expressão em álgebra relacional não possui um nome que possa ser usado para referenciá-la. O operador rename representado pela letra grega rho permite-nos dar nomes a elas. Dada a expressão em álgebra relacional E, a expressão x (E) tem como resultado a expressão E sob o nome x. Visões

Em todas as operações que fizemos até agora, usamos operadores no nível lógico. Isto é, assumimos que as coleções de relações dadas sejam, na verdade, relações armazenadas no banco de dados. Muitas vezes não é desejável que todos os usuários vejam o modelo lógico como um todo. Considerações sobre segurança podem exigir que determinados dados não estejam disponíveis para alguns usuários. Com base em questões de segurança, podemos criar uma coleção de relações personalizadas de relações que se ajustam mais as necessidades do usuário do que ao modelo lógico. Qualquer relação que não faça parte do modelo lógico, mas é visível para o usuário como uma relação virtual é chamada de visão. É possível dar suporte a um grande número de visões sobre qualquer conjunto de relações reais. Definindo Visões Definimos uma visão usando o comando create view. Para definir uma visão, precisamos dar um nome a ela e definir a consulta que criará essa visão. A forma do comando create view é: Create view v as <expressão_de_consulta> Como exemplo considere uma visão consistindo de clientes devedores. Definimos esta visão de clientes_devedores como: Create view clientes_devedores as nome_cliente ( cliente.seguro_social = devedor.seguro_social (cliente X devedor))

Linguagem SQL 1. A linguagem SQL SQL tem representado o padrão para linguagens de banco de dados relacionais. Existem diversas versões de SQL. Essa linguagem, originalmente chamada de SEQUEL, foi implementada como parte do projeto do Sistema R, no início dos anos 70. Inúmeros produtos são suporte atualmente para a linguagem SQL. A linguagem SQL tem diversas partes: linguagem de definição de dados, linguagem interativa de manipulação de dados, incorporação DML, definição de visões, autorização, integridade, controle de transações. 2. Estruturas Básicas A estrutura básica de uma expressão SQL consiste em três cláusulas: select, from e where. A cláusula select corresponde à operação de projeção da álgebra relacional. Ela é usada para relacionar atributos desejados no resultado de uma consulta. A cláusula from corresponde à operação do produto cartesiano da álgebra relacional. Associa ass relações que serão pesquisadas durante a evolução de uma expressão. A cláusula where corresponde à seleção do predicado na álgebra relacional. Ela consiste em um predicado envolvendo atributos da relação que aparece na cláusula from.

O fato de o termo select possuir significado diferente em SQL e na álgebra relacional é infelizmente histórico e precisa ser diferenciada. Uma consulta típica em SQL tem a seguinte forma: Select A1, A2,...,An From r1, r2,,rm Where P Onde, cada Ai representa um atributo e cada ri, uma relação. P é um predicado. A consulta equivalente à seguinte expressão em álgebra relacional seria: A1, A2,...,An ( P (r1 x r2 x...x rm)) Se a cláusula where for omitida, o predicado P é verdadeiro. No entanto, diferente das expressões em álgebra relacional, em SQL o resultado de uma consulta pode ter múltiplas cópias de algumas tuplas. 3. A cláusula Select O resultado de uma consulta SQL é naturalmente uma relação. Consideremos uma consulta simples usando nosso exemplo de banco. encontre todos os nomes de todas as agências da relação empréstimo. Select nome_agência from empréstimo

O resultado é uma relação consistindo de um atributo simples intitulado nome_agência. Se desejarmos, por exemplo, eliminar a duplicidade de linhas, podemos inserir a palavra-chave distinct depois de select. Poderemos reescrever a consulta anterior da seguinte forma: Select distinct nome_agência from empréstimo Ao contrário se quisermos deixar explícito que a duplicidade não será eliminada, podemos usar a palavra-clave all. Select all nome_agência from empréstimo O asterisco * pode denotar todos os atributos na cláusula select. Também poderá haver expressões aritméticas envolvendo os operadores +, -, *, e /. Por exemplo: Select nome_agência, número_empréstimo, total * 100 from empréstimo 4. A cláusula Where Considere a consulta: encontre todos os números de empréstimos feitos na agência Casa Forte, com totais emprestados acima de 1.200 dólares. Esta consulta pode ser escrita como:

Select nome_empréstimo From empréstimo Where nome_agência= Casa Forte and Total > 1200 A SQL utiliza operadores lógicos and, or e not, na cláusula where. A SQL também possui o operador de comparação between para simplificar a cláusula where que especifica que um valor pode ser menor ou igual a algum valor e maior ou igual a algum outro valor. Se desejarmos encontrar os números de empréstimos cujos montantes estejam entre 90 e 100 mil dólares, podemos usar a comparação between escrevendo: Select nome_empréstimo From empréstimo Where total between 90000 and 1000000 Como também podemos usar a combinação de operadores: not between. 5. A cláusula From A cláusula from por si só define um produto cartesiano das relações da cláusula. Para uma consulta: para todos os clientes que tenham empréstimo em um banco, encontre seus nomes e números de empréstimos, em SQL esta consulta pode ser escrita como: Select distinct nome_cliente, devedor.número_empréstimo From devedor, empréstimo Where devedor.número_empréstimo = empréstimo.número_empréstimo