Você está na página 1de 145
Sistemas de Banco de Dados Brasília-DF, 2011.

Sistemas de Banco de Dados

Sistemas de Banco de Dados Brasília-DF, 2011.
Sistemas de Banco de Dados Brasília-DF, 2011.
Sistemas de Banco de Dados Brasília-DF, 2011.

Brasília-DF, 2011.

Sistemas de Banco de Dados Elaboração: Taylor Montedo Machado Produção: Equipe Técnica de Avaliação, Revisão

Sistemas de Banco de Dados

Elaboração:

Taylor Montedo Machado

Produção:

Equipe Técnica de Avaliação, Revisão Linguística e Editoração

2
2

Sumário

Pós-Graduação a Distância

Apresentação

04

Organização do Caderno de Estudos e Pesquisa

05

Organização da Disciplina

06

Introdução

07

Unidade I – Introdução à Modelagem Conceitual

09

Capítulo 1 – Bancos de Dados e seus Usuários

09

Capítulo 2 – Conceitos e Arquiteturas de um SGBD

16

Capítulo 3 – Modelagem de Dados Utilizando o MER

28

Unidade II – Introdução à Modelagem Conceitual

41

Capítulo 4 – Modelo de Dados Relacional

41

Capítulo 5 – Projeto de Banco de Dados Relacional Utilizando o MER

48

Capítulo 6 – SQL – Structured Query Language

52

Unidade III – Teoria e Metodologia do Projeto de Banco de Dados

81

Capítulo 7 – Dependência Funcional e Normalização

81

Capítulo 8 – Metodologia para Projeto Prático de Banco de Dados

92

Unidade IV – Armazenagem de Dados, Indexação, Processamento de Consultas e Projeto Físico

95

Capítulo 9 – Algoritmos para Processamento e Otimização de Consultas

95

Capítulo 10 – Técnicas de Controle de Concorrência

99

Capítulo 11 – Técnicas de Recuperação de Dados

108

Para (não) Finalizar

122

Referências

123

Apêndice I – Palavras-Chave do SQL

124

Apêndice II – Expressões de Valor

137

Apêndice III – Comandos SQL

143

Apresentação

Sistemas de Banco de Dados

Caro aluno,

Bem-vindo ao estudo da disciplina Sistemas de Banco de Dados.

Este é o nosso Caderno de Estudos e Pesquisa, material elaborado com o objetivo de contribuir para a realização e o desenvolvimento de seus estudos, assim como para a ampliação de seus conhecimentos.

Para que você se informe sobre o conteúdo a ser estudado nas próximas semanas, conheça os objetivos da disciplina, a organização dos temas e o número aproximado de horas de estudo que devem ser dedicadas a cada unidade.

A carga horária desta disciplina é de 80 (oitenta) horas, cabendo a você administrar o tempo conforme a sua disponibilidade. Mas, lembre-se, há uma data-limite para a conclusão do curso, incluindo a apresentação ao seu tutor das atividades avaliativas indicadas.

Os conteúdos foram organizados em unidades de estudo, subdivididas em capítulos, de forma didática, objetiva e coerente. Eles serão abordados por meio de textos básicos, com questões para reflexão, que farão parte das atividades avaliativas do curso; serão indicadas, também, fontes de consulta para aprofundar os estudos com leituras e pesquisas complementares.

Desejamos a você um trabalho proveitoso sobre os temas abordados nesta disciplina. Lembre-se de que, apesar de distantes, podemos estar muito próximos.

A Coordenação

Organização do Caderno de Estudos e Pesquisa

Pós-Graduação a Distância

Apresentação: Mensagem da Coordenação.

Organização da Disciplina: Apresentação dos objetivos e da carga horária das unidades.

Introdução: Contextualização do estudo a ser desenvolvido por você na disciplina, indicando a importância desta para sua formação acadêmica.

Ícones utilizados no material didático

Provocação: Pensamentos inseridos no material didático para provocar a reflexão sobre sua prática e seus : Pensamentos inseridos no material didático para provocar a reflexão sobre sua prática e seus sentimentos ao desenvolver os estudos em cada disciplina.

Para refletir: Questões inseridas durante o estudo da disciplina para estimulá-lo a pensar a respeito do assunto proposto. Registre sua visão sem se preocupar com o conteúdo do texto. O importante é verificar seus conhecimentos, suas experiências e seus sentimentos. É fundamental que você reflita sobre as questões propostas. Elas são o ponto de partida de nosso trabalho.Para refletir

Textos para leitura complementar: Novos textos, trechos de textos referenciais, conceitos de dicionários, exemplos e sugestões, para lhe : Novos textos, trechos de textos referenciais, conceitos de dicionários, exemplos e sugestões, para lhe apresentar novas visões sobre o tema abordado no texto básico.

Sintetizando e enriquecendo nossas informações: Espaço para você fazer uma síntese dos textos e enriquecê-los com sua contribuição pessoal. : Espaço para você fazer uma síntese dos textos e enriquecê-los com sua contribuição pessoal.

Sugestão de leituras, filmes, sites e pesquisas : Aprofundamento das discussões. sites e pesquisas: Aprofundamento das discussões.

Praticando: Atividades sugeridas, no decorrer das leituras, com o objetivo pedagógico de fortalecer o processo : Atividades sugeridas, no decorrer das leituras, com o objetivo pedagógico de fortalecer o processo de aprendizagem.

Para (não) finalizar: Texto, ao final do Caderno, com a intenção de instigá-lo a prosseguir com a : Texto, ao final do Caderno, com a intenção de instigá-lo a prosseguir com a reflexão.

Referências: Bibliografia consultada na elaboração da disciplina. : Bibliografia consultada na elaboração da disciplina.

Organização da Disciplina

Sistemas de Banco de Dados

Ementa:

Sistemas de banco de dados. Sistemas de gerenciamento de banco de dados. Modelagem de dados. Modelos conceituais. O modelo relacional. Normalização. A linguagem SQL. Projeto de banco de dados. Implementação de SGBDs. Armazenamento de dados. Estruturas de índices. Processamento e otimização de consultas. Processamento de transações. Controle de concorrência. Recuperação.

Objetivos:

– Contribuir para a capacitação do participante quanto à análise, planejamento, estruturação e implementação de sistemas de gerenciamento de banco de dados.

– Apresentar aos participantes os principais conceitos sobre modelagem, projeto, implementação de sistemas de gerenciamento de banco de dados.

– Estimular a conscientização das potencialidades e restrições inerentes aos sistemas de gerenciamento de banco de dados.

Unidade I – Introdução à Modelagem Conceitual

Carga horária: 20 horas

Conteúdo

Capítulo

Banco de Dados e seus Usuários

1

Conceitos e Arquiteturas de um SGBD

2

Modelagem de Dados Usando o MER

3

Unidade II – Introdução à Modelagem Conceitual

Carga horária: 20 horas

Conteúdo

Capítulo

O Modelo de Dados Relacional

4

Projeto de Banco de Dados Relacional Utilizando o MER

5

SQL – Structured Query Language

6

Unidade III – Teoria e Metodologia do Projeto de Banco de Dados

Carga horária: 20 horas

Conteúdo

Capítulo

Dependência Funcional e Normalização

7

Metodologia para Projeto Prático de Banco de Dados

8

Unidade IV – Armazenamento de Dados, Indexação, Processamento de Consultas e Projeto Físico

Carga horária: 20 horas

Conteúdo

Capítulo

Algoritmos para processamento e Otimização de Consultas

9

Técnicas de Controle de Concorrência

10

Técnicas de Recuperação de Dados

11

Introdução

Pós-Graduação a Distância

Ao olharmos para os processos modernos que nos prestam serviços ou mesmo nos que somos os próprios prestadores de serviços, é possível inferir que existem gigantescas bases de dados que dão suporte ou até mesmo gerenciam nossas vidas. Questões como a nossa conta bancária. As instituições bancárias mantêm bancos de dados que permitem o gerenciamento de todas as transações financeiras realizados. São esses registros que permitem que seja possível acompanhar saldos, aplicações, saques e manter todo histórico de cada conta de cada cliente.

Processos como a apuração das eleições ou mesmo o processamento da declaração do imposto de renda também são suportados por bancos de dados mantidos pelo governo e que permitem que seja possível, como no caso deste último, acompanhar o histórico de cada cidadão.

Sistemas de Banco de Dados 8

Sistemas de Banco de Dados

Unidade I

Pós-Graduação a Distância

Introdução à Modelagem Conceitual

a Distância Introdução à Modelagem Conceitual Capítulo 1 – Bancos de Dados e seus Usuários Hoje

Capítulo 1 – Bancos de Dados e seus Usuários

Conceitual Capítulo 1 – Bancos de Dados e seus Usuários Hoje em dia o termo banco

Hoje em dia o termo banco de dados é bastante popular em diversas áreas de atuação. Com o aumento da utilização de computadores na manipulação de dados que envolvem diversas aplicações, os bancos de dados estão sendo desenvolvidos e aplicados nas diferentes áreas que envolvem o comércio, a indústria, a pesquisa acadêmica, entre outras.

1. Introdução

Segundo Silberschatz (2006), um banco de dados é um conjunto de dados inter-relacionados. Podemos afirmar que esses bancos possuem informações que representam o dia a dia de uma empresa, de uma loja, de uma locadora de vídeo, enfim, de qualquer ambiente que possa ter suas informações coletadas e representadas de uma forma organizada. Tais bancos de dados, além de manter todo esse volume de dados organizado, também devem permitir atualizações, inclusões e exclusões de dados, sem nunca perder a consistência. E, além disso, é necessário considerar que muitas vezes estaremos lidando com vários acessos simultâneos e concorrentes em várias partes diferentes de nosso banco de dados.

Heuser (2001) define dado como sendo um fato do mundo real que está registrado e possui um significado implícito no contexto de um domínio de aplicação. Um banco de dados possui as seguintes propriedades:

• é uma coleção lógica coerente de dados com um significado inerente; uma disposição desordenada dos dados não pode ser referenciada como um banco de dados;

• é projetado, construído e populado com dados para um propósito específico; um banco de dados possui um conjunto pré-definido de usuários e aplicações;

• é representado por algum aspecto do mundo real, o qual é chamado de minimundo; qualquer alteração efetuada no minimundo é automaticamente refletida no banco de dados.

Um banco de dados pode ser criado e mantido por um conjunto de aplicações desenvolvidas especialmente para a tarefa, denominada Sistema de Gerenciamento de Banco de Dados (SGBD). Um SGBD permite aos usuários criar e manipular bancos de dados de propósitos gerais. Silberschatz (2006) define SGBD como sendo uma coleção de dados inter-relacionados e um conjunto de programas para acessar esses dados.

Sistemas de Banco de Dados

Introdução à Modelagem Conceitual

Unidade I

1.1. Metadados

Uma característica importante da abordagem Banco de Dados é que o SGBD mantém não somente os dados, mas também a forma como esses são armazenados, uma vez que contém uma descrição completa do banco de dados.

Essas informações são armazenadas no catálogo do SGBD, o qual contém informações como a estrutura de cada arquivo, o tipo e o formato de armazenamento de cada tipo de dado, restrições. Segundo Heuser (2001), o conjunto de informações armazenadas no catálogo de dados é denominado Metadados.

No processamento tradicional de arquivos, o programa que irá manipular os dados deve conter este tipo de informação, ficando limitado a manipular as informações que ele conhece. Por outro lado, utilizando a abordagem banco de dados, a aplicação pode manipular diversas bases de dados diferentes.

1.2. Programas versus Dados

O processamento tradicional de arquivos pressupõe que a estrutura de dados está incorporada ao próprio programa de acesso. Assim sendo, uma alteração na estrutura de arquivos resulta na alteração do código fonte de todos os programas. Porém, a abordagem de banco de dados permite que as alterações sejam efetuadas apenas no catálogo de dados, sem necessitar alterações nos programas de acesso.

1.3. Abstração de Dados

Uma das funções de um SGBD é fornecer aos usuários uma representação conceitual dos dados sem que, para tanto, necessite fornecer muitos detalhes de como os dados estão armazenados.

Um Modelo de Dados é uma forma de abstração dos dados que é utilizada para fornecer essa representação conceitual, utilizando conceitos lógicos como objetos, suas propriedades e seus relacionamentos (ALVES, 2004).

Os níveis de abstração têm como função, inclusive, ocultar a complexidade e simplificar o processo de interação com os usuários. Sob esse ponto de vista, podemos classificar a abstração em três níveis (SILBERSCHATZ, 2006).

• Físico: é o nível de abstração mais baixo e descreve como os dados são realmente armazenados no banco de dados. Nesse nível, um registro de dado pode ser descrito como um bloco consecutivo de memória.

• Lógico: é nível de abstração intermediário, que descreve que os dados estão armazenados no banco de dados e quais são as relações existentes entre eles. Nesse nível, um registro de dado é descrito por um tipo definido (como um tipo em linguagem de programação) e as inter-relações entre dados são definidas.

Visualização: é o nível de abstração mais alto, que descreve a parte do banco de dados de maior interesse para o usuário final. Nesse nível, podemos dizer que se trata de subconjunto de dados que podem existir apenas durante a execução de uma operação.

1.4. Múltiplas Visões de Dados

Uma vez que um banco de dados deve permitir o acesso de um conjunto diverso de usuários a todo o seu conteúdo, é possível inferir que cada usuário, ou grupo de usuários, pode ter uma necessidade específica. Desse modo, é necessário que cada conjunto de usuário tenha a possibilidade de ter visões diferentes da base de dados.

Assim, uma visão é definida como um subconjunto de uma base de dados, formando desse modo, um conjunto virtual de informações (SILBERSCHATZ, 2006).

Pós-Graduação a Distância

Introdução à Modelagem Conceitual

Unidade I

2. Usuários

Em todo grande banco de dados existe um grande número de pessoas envolvidas que varia desde sua concepção e seu projeto até sua manutenção.

2.1. Administrador de Banco de Dados (DBA)

Um ambiente de banco de dados envolve vários recursos que vão desde o banco de dados em si até o SGBD e outros softwares. Cabe ao Administrador de Banco de Dados (DBA) o seu gerenciamento, envolvendo tarefas como a autorização de acesso a ele, a sua coordenação e a monitoração de seu uso.

2.2. Projetista de Banco de Dados

Cabe ao Projetista de Banco de Dados a identificação dos dados que devem ser armazenados, bem como a definição da estrutura adequada para representá-los e armazená-los. É função do projetista também avaliar as necessidades de cada grupo de usuários para definir as visões que serão necessárias, integrando-as, fazendo com que o banco de dados seja capaz de atender a todas as necessidades dos usuários.

2.3. Usuários Finais

Os usuários finais são as pessoas que utilizam o banco de dados fazendo consultas, atualizações e gerando documentos. Podemos agrupar esses usuários em três categorias:

casuais: acessam o banco de dados casualmente, mas podem necessitar de diferentes informações a cada acesso; utilizam sofisticadas linguagens de consulta para especificar suas necessidades;

novatos ou paramétricos: utilizam porções predefinidas do banco de dados, valendo-se de consultas preestabelecidas que já foram exaustivamente testadas;

usuários avançados: são usuários que estão familiarizados com o SGBD e realizam consultas complexas.

2.4. Analistas de Sistemas e Programadores de Aplicações

Os Analistas de Sistemas são responsáveis pela determinação dos requisitos dos usuários finais e pelo desenvolvimento das especificações para atender aos requisitos mapeados. Por sua vez, os Programadores são responsáveis pela implementação das especificações definidas na forma de programas, testando, depurando, documentando e dando manutenção.

3. Esquemas de Dados

Segundo Silberschatz (2006), os esquemas de dados dizem respeito ao projeto geral do banco de dados e é um aspecto que raramente é modificado.

Um esquema de base de dados é especificado durante o projeto da base de dados e a forma de visualização de um esquema é chamada Diagrama do Esquema.

Os SGBDs possuem vários esquemas de banco de dados que variam em função do nível de abstração dos dados:

esquema físico: tem como objetivo descrever o projeto do banco de dados no nível físico;

esquema lógico: diz respeito à descrição do banco de dados no nível lógico;

subesquema de visualização: diz respeito à descrição das visualizações possíveis para um banco de dados.

Muitos modelos de dados têm certas convenções para, diagramaticamente, mostrar esquemas especificados neles.

Sistemas de Banco de Dados

Introdução à Modelagem Conceitual

Unidade I

Alguns autores defendem que uma das maiores contribuições dos primeiros SGBDs foi introduzir a separação entre os dados armazenados e a descrição da estrutura dos dados, o esquema de dados.

4. Vantagens e desvantagens do uso de um SGBD

Como toda e qualquer ferramenta, o uso de banco de dados apresenta um conjunto de vantagens e desvantagens quanto ao seu uso.

4.1. Desvantagens

4.1.1. Altos Custos

As organizações têm se tornado cada vez mais complexas e os processos de negócio, por sua vez, refletem a necessidade da disponibilidade de dados de forma rápida, precisa e flexível. Como conseqüência, os bancos de dados acabam por se tornar cada vez mais complexos, volumosos e onerosos.

Apesar dos custos relativos ao armazenamento de dados estarem sendo reduzidos em ritmo acelerado, juntamente com

a popularização do hardware necessário, aspectos como a concepção, o gerenciamento e a manutenção de bancos de

dados cada vez mais pesam no orçamento de seu projeto. Por vezes, os custos podem se tornar um empecilho para a adoção de um banco de dados.

4.1.2. Gerenciamento e Manutenção

A par e passo com a evolução da necessidade de informações, os bancos de dados também necessitam de manutenção

evolutiva e/ou corretiva. Uma vez que um processo na organização, que é suportado por um banco de dados, sofre alguma mudança, a necessidade de informações para geri-lo adequadamente também muda. Além disso, a evolução tecnológica dos SGBDs imprime a necessidade de ajustes de versão de software e/ou upgrades para que seja possível usufruir dos benefícios que estes sistemas oferecem.

Desse modo, a necessidade de uma estrutura para gerenciar o banco de dados, bem como a necessidade de mantê-lo, gera custos que podem tornar o seu uso proibitivo.

4.2. Vantagens

4.2.1. Controle de Redundância

No processamento tradicional de tratamento de arquivos, é necessário que cada grupo de usuários mantenha seu próprio conjunto de arquivos e dados, o que pode fazer com que acabe ocorrendo redundâncias que prejudiquem o sistema com problemas como:

• toda vez que for necessário atualizar um arquivo de um grupo, todos os grupos devem ser atualizados para manter a integridade dos dados no ambiente como um todo;

• a redundância desnecessária de dados leva ao armazenamento excessivo de informações, ocupando espaço que poderia estar sendo utilizado com outras informações.

4.2.2. Compartilhamento de Dados

A utilização de um SGBD permite que múltiplos usuários acessem o banco de dados ao mesmo tempo, permitindo que múltiplas aplicações integradas possam acessá-lo.

O SGBD multiusuário necessita manter o controle de acessos simultâneos (concorrência) para assegurar a qualidade do resultado de atualizações, bem como fornecer recursos que permitam a construção de múltiplas visões.

Pós-Graduação a Distância

Introdução à Modelagem Conceitual

Unidade I

4.2.3. Restrição a Acesso não Autorizado

Um SGBD permite que seja criado um subsistema de autorização e segurança, o qual é utilizado pelo DBA para criar contas de acesso e especificar as restrições de cada conta, sendo estendido tanto para acesso aos dados quanto ao uso de softwares inerentes ao SGBD.

4.2.4. Representação de Relacionamentos Complexos entre Dados

Um banco de dados permite que seja catalogada uma variedade de dados que estão inter-relacionados de várias formas. Por sua vez, um SGBD fornece uma série de recursos para representar uma grande variedade de relacionamentos entre os dados, bem como recuperá-los e atualizá-los de maneira prática e eficiente.

4.2.5. Padronização

A abordagem de base de dados permite que o DBA defina e obrigue a padronização entre os usuários da base de dados

em grandes organizações. Isso facilita a comunicação e a cooperação entre vários departamentos, projetos e usuários. Padrões podem ser definidos para formatos de nomes, elementos de dados, telas, relatórios, terminologias.

É possível utilizar esse recurso, com maior facilidade, em um ambiente de base de dados centralizado, em comparação com um ambiente onde cada usuário ou grupo tem o controle de seus próprios arquivos e programas de aplicação.

4.2.6. Flexibilidade

Mudanças nos requisitos podem acarretar a necessidade de modificações na estrutura de um banco de dados. Por exemplo, um novo grupo de usuários pode surgir com necessidade de informações adicionais, ainda não disponíveis na base de dados. Alguns SGBDs permitem que tais mudanças na estrutura da base de dados sejam realizadas sem afetar

a maioria dos programas de aplicações existentes.

4.2.7. Redução do Tempo de Desenvolvimento de Aplicações

Uma das características mais significativas da abordagem de base de dados é o tempo reduzido para o desenvolvimento de novas aplicações, como a recuperação de certos dados da base de dados para a impressão de novos relatórios.

Projetar e implementar uma nova base de dados pode tomar mais tempo do que escrever uma simples aplicação especializada de arquivos. Porém, uma vez que a base de dados esteja em uso, geralmente é bastante reduzidoo tempo para se criar novas aplicações, usando-se os recursos de um SGBD. O tempo para se desenvolver uma nova aplicação em um SGBD é estimado em 1/4 a 1/6 do tempo de desenvolvimento, usando-se apenas o sistema de arquivos tradicional, devido às facilidades de interfaces disponíveis em um SGBD.

4.2.8. Disponibilidade de Informações Atualizadas

A abordagem de banco de dados permite que tão logo um usuário modifique uma base de dados, todos os outros usuários

podem usufruir imediatamente dessa modificação. Essa disponibilidade de informações atualizadas é essencial para muitas aplicações, tais como sistemas de reservas de passagens aéreas ou bases de dados bancárias.

4.2.9. Economia de Escala

A abordagem de banco de dados permite a consolidação de dados e de aplicações, reduzindo-se, desse modo, o desperdício em atividades redundantes de processamento em diferentes projetos ou departamentos.

4.3. Quando não Utilizar um SGBD

Não raro, o uso de um SGBD pode representar um acréscimo desnecessário de custos, se comparado à abordagem de processamento tradicional de arquivos. Exemplificando, podemos ter:

Sistemas de Banco de Dados

Introdução à Modelagem Conceitual

Unidade I

• alto investimento inicial na compra de software e hardware adicionais;

• generalidade que um SGBD fornece na definição e processamento de dados;

• sobrecarga na provisão de controle de segurança, de controle de concorrência, na recuperação e na integração de funções.

É necessário reconhecer que problemas adicionais podem ocorrer como da resultado especificação inadequada do projeto e/ou da implementação das aplicações de forma não apropriada. Caso o DBA não administre o banco de dados de forma adequada, tanto a segurança quanto a integridade dos sistemas podem ser comprometidas. A sobrecarga causada pelo uso de um SGBD e a má administração justificam a utilização da abordagem de processamento tradicional de arquivos em casos como:

• o banco de dados e as aplicações sejam simples, bem-definidos e não sejam esperadas mudanças no projeto;

• sejá necessário processamento em tempo real de certas aplicações, que são terrivelmente prejudicadas pela sobrecarga causada pelo uso de um SGBD;

• não haja múltiplo acesso ao banco de dados.

5. Um Breve Histórico da Aplicação de Banco de Dados

Entre a década de 1950 e o início dos anos 1960, as fitas magnéticas eram utilizadas para o armazenamento de dados

e as tarefas de processamento de dados eram efetuadas quase que de forma mecanizada. Os registros também podiam ser alimentados por decks de cartão perfurado e necessitavam que fossem carregados seqüencialmente, na mesma ordem em que estavam gravados nas fitas magnéticas.

No final dos anos 1960, a tecnologia de armazenamento em discos rígidos levou a uma mudança radical no cenário do processamento de dados, pois permitiam o acesso direto aos dados, independentemente de sua posição no disco.

Entre as décadas de 1960 e 1970, várias pesquisas foram desenvolvidas no sentido de desenvolver tecnologias que permitissem a simplificação dos processos de escritório que conduziram à automação. Tarefas como armazenar e organizar arquivos, que dependiam única e exclusivamente de mão-de-obra intensiva, poderiam ser simplificadas com o uso de soluções mecânicas mais eficientes e mais baratas. Desse modo, muitas pesquisas foram desenvolvidas e resultaram na criação dos modelos hierárquicos, de rede e relacionais.

Nesse cenário, empresas, como a IBM, tomaram a dianteira e, em 1970, um pesquisador daquela empresa, Ted Codd, publicou o primeiro artigo sobre bancos de dados relacionais, que tratava de um método que permitia que usuários não técnicos pudessem armazenar e recuperar grande quantidade de dados, a partir da utilização de comandos que manipulassem dados armazenados em tabelas.

Na década de 1980, com base nesse estudom, a IBM montou um grupo de pesquisa conhecido como Sistema R (System R)

que objetivava a criação de um banco de dados relacional que tivesse viabilidade comercial. O primeiro sistema comercial baseado no conceito desenvolvido pela IBM, foi lançado em 1976 pela Honeywell Information Systems Inc. No entanto,

o

primeiro SGBD construído nos padrões SQL só começou a surgir no mercado a partir do início da década de 1980 com

o

Oracle 2, da empresa Oracle, e, posteriormente, com o SQL/DS, da IBM.

No início da década de 1990, um dos produtos do Sistema R foi a criação de uma linguagem denominada SQL – Structured Query Language (Linguagem de Consulta Estruturada). A linguagem SQL tornou-se um padrão na indústria para bancos de dados relacionais e hoje em dia, é um padrão ISO (International Organization for Standardization 1 ), o que permitiu o desenvolvimento e refinamento de softwares de banco de dados relacionais. Outros aspectos relevantes que contribuíram para o refinamento e popularização dos bancos de dados relacionais foram: o retorno que os usuários desses sistemas davam para o aprimoramento da linguagem, o desenvolvimento de sistemas para novas indústrias e

1 A ISO é a organização internacional de padronização responsável pelos padrões técnicos internacionais

Pós-Graduação a Distância

Introdução à Modelagem Conceitual

Unidade I

aumento do uso de computadores pessoais e sistemas distribuídos. O padrão SQL passou da IBM para a ANSI (American National Standards Institute) – Instituto Nacional Americano para Padrões que, juntamente com a ISO, formaram um grupo de trabalho para continuar o desenvolvimento. Este desenvolvimento ainda acontece com outras novas versões dos padrões definidos até os dias atuais.

O final da década de 1990 foi marcado pela massificação do uso da World Wide Web (WWW), fazendo com que os sistemas de banco de dados tivessem de trabalhar com taxas de processamento de transação cada vez maiores e disponibilidade de 24x7, ou seja, disponibilidade 24 horas por dia, 7 dias por semana.

Em meados de 2000, surge a Linguagem Extensível de Formatação ou Extended Markup Language (XML) como uma nova tecnologia de banco de dados. O XML é uma especificação técnica desenvolvida pela W3C – World Wide Web Consortium 1 .

1 A W3C é a entidade responsável pela definição da área gráfica da internet. (http://www.w3.org).

Sistemas de Banco de Dados

Introdução à Modelagem Conceitual

Unidade I

Capítulo 2 – Conceitos e Arquiteturas de um SGBD

I Capítulo 2 – Conceitos e Arquiteturas de um SGBD Tenha certeza da completa compreensão das

Tenha certeza da completa compreensão das informações organizacionais durante o estudo de Modelagem Conceitual, pois inseguranças durante os estágios posteriores da disciplina podem ser extremamente caras, prejudicando a aprendizagem.

1. Modelos de Dados, Esquemas e Instâncias

1.1. Esquemas e Instâncias

Uma distinção importante para qualquer modelo de dados é a que deve ser feita entre a descrição do banco de dados e o próprio banco. A descrição de um banco de dados é chamada de esquema de um banco de dados e é especificada durante

o projeto do banco de dados. Geralmente, poucas mudanças ocorrem no esquema do banco de dados.

Uma instância 1 do banco de dados diz respeito à coleção de dados armazenados em um banco de dados em um determinado momento (SILBERSCHATZ, 2006). A instância modifica toda vez que uma alteração no banco de dados é feita. O SGBD é responsável por garantir que toda instância do banco de dados satisfaça o seu esquema do banco de dados, respeitando sua estrutura e suas restrições.

O esquema de um banco de dados também pode ser chamado de intensão de um banco de dados e a instância, de extensão de um banco de dados.

A diferenciação entre esquema e instância de um banco de dados pode ser melhor compreendida fazendo uma analogia com um programa, conforme ilustrado na Figura 2.1.

Figura 2.1 Analogia entre um Programa e um Banco de Dados

Declaração da

Variável

PROGRAMA

Valor da

Variável

da Variável PROGRAMA Valor da Variável 1.2. Modelos de Dados Esquema do Banco de Dados BANCO
da Variável PROGRAMA Valor da Variável 1.2. Modelos de Dados Esquema do Banco de Dados BANCO

1.2. Modelos de Dados

Esquema do Banco de Dados

BANCO DE DADOS

Instância do Banco de Dados

Uma das vantagens mais relevantes de um banco de dados é a possibilidade de fornecer alguns níveis de abstração de dados para o usuário final, omitindo os detalhes de como estes são armazenados.

1 Também pode ser chamada de ocorrência ou estado de um banco de dados

Pós-Graduação a Distância

Introdução à Modelagem Conceitual

Unidade I

Segundo Silberschatz, um Modelo de Dados é uma coleção de ferramentas conceituais para descrever dados, relações de dados, semântica de dados e restrições de consistência. Um modelo de dados permite descrever a estrutura 1 de um banco de dados de forma lógica e física. Além disso, vários Modelos de Dados também definem um conjunto de operações para especificar como recuperar e modificar a base de dados.

Desse modo, podemos dizer que o Modelo de Dados é a principal ferramenta que fornece a abstração a um BD.

Os modelos de dados podem ser basicamente de dois tipos:

alto nível: ou modelo conceitual de dados, que fornece uma visão mais próxima do modo como os usuários realmente visualizam os dados;

baixo nível: ou modelo físico de dados, que fornece uma visão mais detalhada do modo como os dados estão realmente armazenados no computador.

1.2.1. Modelo de Dados Hierárquico

O primeiro modelo de dados a ser reconhecido foi o modelo hierárquico, que só pôde ser desenvolvido devido à consolidação dos discos de armazenamento endereçáveis. Esses discos possibilitaram a exploração de sua estrutura de endereçamento físico para viabilizar a representação hierárquica das informações.

No modelo hierárquico, os dados são estruturados em hierarquias ou árvores. Os nós das hierarquias contêm ocorrências de registros, onde cada registro é uma coleção de campos (atributos), cada um contendo apenas uma informação.

O registro-pai é o registro da hierarquia que precede a outros, sendo esses outros denominados registros-filhos. Uma

ligação é uma associação entre dois registros. Possui cardinalidade 1:N o relacionamento entre um registro-pai e vários registros-filhos.

Organizando os dados segundo o modelo hierárquico, esses podem ser acessados por meio de uma seqüência hierárquica com uma navegação do topo para as folhas e da esquerda para a direita. Um registro pode estar associado a vários registros diferentes, desde que seja replicado.

O Information Management System da IBM Corp (IMS) foi o sistema comercial mais divulgado no modelo hierárquico.

Uma boa parte das restrições e consistências de dados estava contida dentro dos programas escritos para as aplicações Para acessar o banco de dados, era necessário escrever os programas na ordem.

O esquema de um banco de dados hierárquico é descrito por meio de um diagrama de estrutura de árvore. Tal diagrama

consiste em dois componentes básicos: Caixas, as quais correspondem aos tipos de registros, e Linhas, que correspondem às ligações entre os tipos de registros. Como exemplo do modelo hierárquico, considere a Figura 2.2.

Figura 2.2. Diagrama de Estrutura de Árvore Cliente-Conta Corrente

Nome Rua Cidade N o Conta Corrente Saldo João R121 Brasília Pedro R231 Guará 51935
Nome
Rua
Cidade
N o Conta Corrente
Saldo
João
R121
Brasília
Pedro
R231
Guará
51935
100,00
61893
500,00

Fonte: Adaptado de Silberschatz (2006).

1 Por estrutura podemos compreender o tipo dos dados, os relacionamentos e as restrições que podem recair sobre os dados.

Sistemas de Banco de Dados

Introdução à Modelagem Conceitual

Unidade I

O Modelo Hierárquico apresenta algumas restrições devido a:

• complexidade dos diagramas de estrutura de árvore;

• não permitir ciclos no gráfico básico de um diagrama de estrutura de árvore;

• existência de restrições à cardinalidade dos links (de muitos para muitos (N:M) e de muitos para um (N:1));

• ausência de facilidades de consultas declarativas;

• necessidade de navegação por ponteiros para acesso à informações;

• alta complexidade das consultas.

Além disso, a replicação possui duas grandes desvantagens: pode causar inconsistência de dados, quando houver atualização, e o desperdício de espaço é inevitável.

1.2.2. Modelo de Dados de Rede

O surgimento do modelo de rede deu-se como uma extensão ao modelo hierárquico; dessa forma, foi eliminando o conceito de hierarquia e permitindo que um mesmo registro estivesse envolvido em várias associações.

Os registros, no modelo em rede, são organizados em grafos onde aparece um único tipo de associação (set) que define uma relação 1:N entre 2 tipos de registros: proprietário e membro. Nesse sentido, é possível construir um relacionamento M:N entre A e D, dados dois relacionamentos 1:N entre os registros A e D e entre os registros C e D.

Com linguagem própria para definição e manipulação de dados, o gerenciador Data Base Task Group (DBTG) da CODASYL (Committee on Data Systems and Languages) estabeleceu uma norma para esse modelo de banco de dados. Como os dados tinham uma forma limitada de independência física, a única garantia era que o sistema deveria recuperar os dados para as aplicações como se eles estivessem armazenados na maneira indicada nos esquemas.

Concorrência e segurança foram definidas, pelos geradores de relatórios da CODASYL, como dois aspectos chaves dos sistemas gerenciadores de dados. Para cada um desses aspectos foram definidas sintaxes. O mecanismo de segurança fornecia uma facilidade em que parte do banco de dados (ou área) pudesse ser bloqueada para prevenir acessos simultâneos, quando necessário. A sintaxe da segurança permitia que uma senha fosse associada a cada objeto descrito no esquema.

Ao contrário do modelo hierárquico, o modelo em rede possibilita acesso a qualquer nó da rede sem passar pela raiz. O CAIDMS da Computer Associates é o sistema comercial mais divulgado do modelo em rede. O diagrama para representar os conceitos do modelo em redes consiste em dois componentes básicos: Caixas, que correspondem aos registros, e Linhas, que correspondem às associações. A Figura 2.3 ilustra um exemplo de diagrama do modelo em rede.

Figura 2.3. Diagrama Esquemático da Estrutura de Dados Cliente-Conta Corrente

Cliente Conta Nome Rua Cidade N o Conta Corrente Saldo R_Link Cliente Conta Pedro R231
Cliente
Conta
Nome
Rua
Cidade
N o Conta Corrente
Saldo
R_Link
Cliente
Conta
Pedro
R231
Guará
61893
500,00
João
R121
Brasília
51935
100,00
R_Link

Fonte: Adaptado de Silberschatz (2006).

Pós-Graduação a Distância

Introdução à Modelagem Conceitual

Unidade I

O Modelo de Rede apresenta algumas restrições devido:

• forte dependência da implementação;

• necessidade de criação de registros artificiais para implementar relacionamentos muitos para muitos;

• alta complexidade das consultas, pois o programador é forçado a pensar em termos de links e como percorrê- los para obter as informações necessárias (manipulação de dados navegacional).

1.2.3. Modelo de Dados Relacional

O modelo relacional surgiu devido às necessidades de aumentar a independência de dados nos sistemas gerenciadores de

banco de dados; de prover um conjunto de funções apoiadas em álgebra relacional para armazenamento e recuperação de dados, de permitir o processamento ad hoc1. Esse modelo, tendo por base a teoria dos conjuntos e a álgebra relacional, foi resultado de um estudo teórico realizado por CODD[1]2.

Esse modelo foi o que revelou ser o mais flexível e adequado ao solucionar os vários problemas que se colocam no nível da concepção e implementação da base de dados. Sua estrutura fundamental é a relação (tabela). Uma relação é

constituída por um ou mais atributos (campos) que traduzem o tipo de dados a armazenar. Tupla (registro) é o nome dado

a

cada instância do esquema (linha).

O

modelo relacional não tem caminhos pré-definidos para se fazer acesso aos dados como nos modelos que o precederam

e

implementa estruturas de dados, organizadas em relações.

Figura 2.4. Diagrama de Estrutura Relacional Cliente-Conta Corrente

Cód_Cliente N o Conta Corrente N o Conta Corrente Saldo Cód_Cliente Nome Rua Cidade 1
Cód_Cliente
N o Conta Corrente
N o Conta Corrente
Saldo
Cód_Cliente
Nome
Rua
Cidade
1 João
R121
Brasília
2 Pedro
R231
Guará
Cód_Cliente
N o Conta Corrente
N o Conta Corrente
Saldo
1 61893
61893
500,00
2 51935
51935
100,00

Cód_Cliente

Nome

Rua

Cidade

Fonte: Adaptado de Silberschatz (2006).

Algumas restrições devem ser impostas para que se trabalhe com essas tabelas e evitar aspectos indesejáveis como: repetição de informação, incapacidade de representar parte da informação e perda de informação. Essas restrições são: integridade referencial, chaves e integridade de junções de relações. A Figura 2.4 traz exemplos de tabelas sob o modelo relacional.

1.2.4. Modelo de Dados Orientado a Objetos

Em meados de 1980, começaram a se tornar comercialmente viáveis os bancos de dados orientados a objeto. Seu surgimento foi motivado em função dos limites de armazenamento e representação semântica impostas no modelo relacional. Os sistemas de informações geográficas (SIG), os sistemas CAD e CAM, que são mais facilmente construídos usando tipos complexos de dados, são alguns dos exemplos que podem ser citados.

Sistemas de Banco de Dados

Introdução à Modelagem Conceitual

Unidade I

Uma característica das linguagens de programação orientadas a objetos é a habilidade para criar os tipos de dados necessários. Contudo, esses sistemas necessitam guardar representações das estruturas de dados que utilizam no armazenamento permanente.

O ODMG (Object Database Management Group) foi quem criou a estrutura padrão para os bancos de dados orientados a

objetos. Esse grupo é formado por representantes dos principais fabricantes desses bancos disponíveis comercialmente.

Os membros do grupo têm o compromisso de incorporar o padrão em seus produtos.

Modelo Orientado a Objetos é um termo usado para documentar o padrão que contém a descrição geral das facilidades

de um conjunto de linguagens de programação orientadas a objetos e a biblioteca de classes que pode formar a base para

o Sistema de Banco de Dados. Algumas das falhas perceptíveis do modelo relacional pareceram ter sido solucionadas

quando os bancos de dados orientados a objetos foram introduzidos e acreditava-se que tais bancos de dados ganhariam grande parcela do mercado.

Acredita-se que nos dias atuais, enquanto os sistemas relacionais continuarão a sustentar os negócios tradicionais, onde as estruturas de dados baseadas em relações são suficientes, os Bancos de Dados Orientados a Objetos serão usados em aplicações especializadas.

O diagrama de classes UML serve geralmente como o esquema para o modelo de dados orientado a objetos. Observe o exemplo da Figura 2.5. e compare as diferenças com o modelo anterior.

Figura 2.5. Diagrama UML Cliente-Conta Corrente

Cliente Conta 1 * 1 * Nome: String N o Conta Corrente: Inteiro Rua: String
Cliente
Conta
1
*
1
*
Nome: String
N o Conta Corrente: Inteiro
Rua: String
Saldo: Real
Cidade: String

Fonte: Adaptado de Silberschatz (2006).

1.2.5. Modelo de Dados para Sistemas Objeto-Relacionais

Os sistemas relacionais convencionais têm dificuldade de representar e manipular dados complexos, visando ser mais representativos em semântica e construções de modelagens; com isso, a área de atuação dos sistemas Objeto-Relacional tenta suprir essas dificuldades. A solução proposta é a adição de facilidades para manusear tais dados utilizando-se das facilidades SQL (Structured Query Language) existentes. Para isso, foi necessário adicionar: extensões dos tipos básicos no contexto SQL; representações para objetos complexos no contexto SQL; herança no contexto SQL e sistema para produção de regras.

1.3. A Arquitetura Três Esquemas

O principal objetivo da arquitetura três esquemas é permitir a separação das aplicações do usuário do banco de dados

físico. Uma representação gráfica da arquitetura três esquemas é apresentada na Figura 2.6. Com base nessa arquitetura,

é possível classificar os esquemas:

nível interno: ou esquema interno, que descreve a estrutura de armazenamento físico do banco de dados; utiliza um modelo de dados e descreve detalhadamente os dados armazenados e os caminhos de acesso ao banco de dados;

nível conceitual: ou esquema conceitual, que descreve a estrutura do banco de dados como um todo; é uma descrição global do banco de dados, que não fornece detalhes do modo como os dados estão fisicamente armazenados;

Pós-Graduação a Distância

Introdução à Modelagem Conceitual

Unidade I

nível externo: ou esquema de visão, que descreve as visões do banco de dados para um grupo de usuários; cada visão descreve as porções do banco de dados às quais um grupo de usuários terá acesso.

1.4. Independência de Dados

Segundo Oppel (2004), é possível definir a independência de dados como a capacidade de se alterar um esquema em um nível em um banco de dados sem ter que alterar um nível superior. É possível classificar a independência de dados em dois tipos:

• independência de dados lógica: é a capacidade de alterar o esquema conceitual sem ter que alterar o esquema externo ou as aplicações do usuário;

• independência de dados física: é a capacidade de alterar o esquema interno sem ter que alterar o esquema conceitual, o esquema externo ou as aplicações do usuário.

Figura 2.6. Arquitetura Três Esquemas

NÍVEL EXTERNO Usuários Finais Visão Externa 1 Mapeamento Conceitual Externo NÍVEL CONCEITUAL Esquema
NÍVEL
EXTERNO
Usuários Finais
Visão Externa 1
Mapeamento
Conceitual
Externo
NÍVEL
CONCEITUAL
Esquema Conceitual
Mapeamento
NÍVEL
Conceitual
Esquema Interno
INTERNO
Externo
Banco de Dados Armazenado

2. Linguagens de Banco de dados

Cada camada e/ou função de um banco de dados necessita de um tipo de linguagem específica, conforme podemos ver.

2.1. Linguagem de Definição de Dados

A Linguagem de Definição de Dados ou Data Definition Language (DDL) é a linguagem utilizada pelo DBA e pelos projetistas de banco de dados para definir seus esquemas. O SGBD, por sua vez, possui um compilador para processar descrições em DDL e construir a descrição do esquema armazenado no catálogo.

Sistemas de Banco de Dados

Introdução à Modelagem Conceitual

Unidade I

2.2. Linguagem de Manipulação de Dados

A Linguagem de Manipulação de Dados ou Data Manipulation Language (DML) é a linguagem pela qual os usuários

manipulam os dados em um SGBD. Manipulações comuns como recuperação, inserção, remoção e modificação de dados são realizadas pela DML.

2.3. Linguagem de Definição de Armazenamento

Em situações onde a separação entre os níveis conceitual e interno de um SGBD é bem clara, utiliza-se a Linguagem de Definição de Armazenamento ou Storage Definition Language (SDL) para a especificação do esquema interno, sendo que a especificação do esquema conceitual fica por conta da DDL.

2.4. Linguagem de Definição de Visões

Sistemas de Banco de Dados que utilizam a arquitetura três esquemas necessitam de uma linguagem para a definição de visões, a Linguagem de Definição de Visões ou Vision Definition Language (VDL).

3. O Ambiente de Sistemas de Banco de Dados

O Ambiente dos Sistemas de Banco de Dados diz respeito ao conjunto de elementos necessário para que ocorram as

transações relativas ao armazenamento, processamento e recuperação de dados, conforme representado pela Figura 2.7.

3.1. Componentes de um Sistema Gerenciador de Banco de Dados

3.1.1. Processamento de Consultas

O componente de processamento de consultas é composto pelos seguintes elementos:

Compilador DML: é o elemento que traduz os comandos DML em instruções de baixo nível, entendidos pelo componente de execução de consultas. Também é responsável pela otimização de solicitações do usuário.

Pré-compilador para comandos DML inseridos em programas de aplicação: são os elementos que convertem comandos DML em chamadas de procedimentos normais da linguagem hospedeira. Também interagem com o compilador DML de modo a gerar o código apropriado.

Interpretador DDL: é o elemento que interpreta os comandos DDL e os registra no dicionário de dados.

Componente de execução de consultas: é o elemento que executa instruções de baixo nível geradas pelo compilador DML.

Pós-Graduação a Distância

Introdução à Modelagem Conceitual

Unidade I

Figura 2.7. Um ambiente de Sistema de Banco de Dados

I Figura 2.7. Um ambiente de Sistema de Banco de Dados Usuários Usuários Programadores de Administradores
Usuários Usuários Programadores de Administradores Usuários Navegadores Avançados Aplicações de BD
Usuários
Usuários
Programadores de
Administradores
Usuários
Navegadores
Avançados
Aplicações
de BD
Interface com
Programas de
Consultas
Interface
Aplicações
Aplicações
(Queries)
Esquema de
Banco de Dados
Programas de
Pré-compilador de
Aplicações em
Compilador DML
Interpretador DDL
Comandos DML
Código Objeto
Gerenciador de
Gerenciador de
Buffer
Transações
Gerenciador de
Arquivos
Banco de
Arquivos de
Dados
Dicionário de
Índices
Dados
Dados
Estatísticos
Dados
Ambiente do Sistema Gerenciador de Bando de Dados
Sistema Gerenciador de
Banco de Dados
Gerenciador de
Processador de
Memória
Consultas

Fonte: Adaptado de Silberschatz (2006).

3.1.2. Gerenciador de Memória

de Silberschatz (2006). 3.1.2. Gerenciador de Memória O componente Gerenciador de Memória é o responsável por

O componente Gerenciador de Memória é o responsável por traduzir os diversos comandos DML em comandos de baixo

nível de sistemas de arquivos, o que lhe confere especial importância uma vez que um dos principais objetivos de um

SGBD é simplificar e otimizar o acesso aos dados. Visto que esse componente é responsável por fazer a interface entre

o armazenamento de dados em um nível mais baixo e as consultas e programas de aplicações submetidos ao sistema, é possível afirmar que o Gerenciador de Memória é um dos principais elementos de um SGBD.

O componente de gerenciamento de memória é composto pelos seguintes elementos:

Gerenciamento de Autorizações e Integridade: são os elementos que testam o cumprimento das regras de integridade e a permissão ao usuário no acesso ao dado.

Gerenciamento de Transações: são os elementos responsáveis pela execução das transações.

Administração de Buffer 1 : é o elemento responsável pela intermediação de dados do disco para a memória principal e pela decisão de quais dados alocar em memória auxiliar.

• Administração de Arquivos: é o elemento que gerencia a alocação de espaço no armazenamento em disco e as estruturas de dados usadas para representar essas informações armazenadas.

1 Unidade de armazenamento temporária (relativo a computador). Fonte: http://www.merriam-webster.com/dictionary

Sistemas de Banco de Dados

Introdução à Modelagem Conceitual

Unidade I

3.1.3. Módulo Banco de Dados

O Módulo Banco de Dados não se limita apenas a armazenar dados, uma vez que também contém definições e descrições

sobre a estrutura que forma o Banco de Dados (metadados). Os metadados, por sua vez, contêm definições da estrutura de cada arquivo, o tipo e formato de armazenamento de cada item de dados e as restrições dos dados. Todas essas definições ficam armazenadas no Catálogo de Dados (dicionário de dados) do Banco de Dados e são utilizadas pelo SGBD.

O Módulo Banco de Dados é composto por:

• Arquivo de Dados: é o elemento que armazena os dados (o banco de dados propriamente dito).

• Dicionário de Dados: é o elemento que armazena os metadados.

• Índices: é o elemento estrutural que otimiza o acesso aos itens de dados.

• Estatística de Dados: é o elemento que armazena informações estatísticas relativas aos dados contidos no banco de dados. Essas informações são usadas pelo processador de consultas para seleção de meios eficientes para execução de consultas.

3.3. Arquiteturas de Banco de Dados

Os mainframes eram utilizados pelas primeiras arquiteturas para executar o processamento principal e de todas as funções do sistema, incluindo os programas aplicativos, programas de interface com o usuário, bem como a funcionalidade dos SGBDs. Essa é a razão pela qual a maioria dos usuários fazia acesso aos sistemas via terminais que não possuíam poder de processamento, mas, somente a capacidade de visualização. Apenas as informações a serem visualizadas e os controles eram enviados do mainframe para os terminais de visualização e todos os processamentos eram feitos remotamente, conectados a ele por redes de comunicação.

Muitos usuários trocaram seus terminais por Computadores Pessoais (PC) e estações de trabalho devido à queda dos preços do hardware. No começo, os SGBDs usavam esses computadores da mesma maneira que usavam os terminais.

O SGBD era centralizado e toda sua funcionalidade, execução de programas aplicativos e processamento da interface do usuário eram executados em apenas uma máquina.

Os SGBDs, gradualmente, começaram a explorar a disponibilidade do poder de processamento no lado do usuário, o que levou à arquitetura cliente-servidor. Essa arquitetura foi desenvolvida para dividir ambientes de computação onde um grande número de PCs, estações de trabalho, servidores de arquivos, impressoras, servidores de banco de dados e outros equipamentos são conectados juntos por uma rede.

A idéia era definir servidores especializados, tais como servidor de arquivos, que mantém os arquivos de máquinas clientes, ou servidores de impressão que podem estar conectados a várias impressoras; assim, quando se desejar imprimir algo, todas as requisições de impressão são enviadas a esse servidor. As máquinas clientes disponibilizam para o usuário as interfaces apropriadas para utilizar esses servidores, bem como o poder de processamento para executar aplicações locais.

A arquitetura cliente-servidor se tornou muito popular por causa da facilidade de implementação dada à clara separação

das funcionalidades e dos servidores; pelo servidor ser inteligentemente utilizado porque as tarefas mais simples são

delegadas às máquinas-clientes mais baratas e também porque o usuário pode executar uma interface gráfica que lhe é familiar, ao invés de usar a interface do servidor.

Aos SGBDs comerciais, foi incorporada a arquitetura cliente-servidor e diferentes técnicas foram propostas para se implementar essa arquitetura, sendo que a mais adotada pelos Sistemas Gerenciadores de Banco de Dados Relacionais (SGBDRs) comerciais é a inclusão da funcionalidade de um SGBD centralizado no lado do servidor. Permanecem no servidor de consulta ou servidor de transação as consultas e a funcionalidade transacional. É assim que um servidor SQL é fornecido aos clientes.

Pós-Graduação a Distância

Introdução à Modelagem Conceitual

Unidade I

Os clientes têm que formular suas consultas SQL, prover a interface do usuário e as funções de interface usando uma linguagem de programação. Podem também se referir a um dicionário de dados, que inclui informações sobre a distribuição dos dados em vários servidores SQL, bem como sobre os módulos para a decomposição de uma consulta global em um número de consultas locais que podem ser executadas em vários sítios.

O servidor SQL também é chamado de back-end machine e o cliente de front-end machine. Como SQL provê uma linguagem padrão para o SGBDRs, esta criou o ponto de divisão lógica entre o cliente e o servidor.

Atualmente, existem várias tendências para arquitetura de Banco de Dados, nas mais diversas direções.

As principais arquiteturas de SGBDs são:

• Plataformas centralizadas: nessa arquitetura existe um computador com grande capacidade de processamento, sendo esse o hospedeiro do SGBD e emulador para os vários aplicativos. Sua principal vantagem é a de permitir que muitos usuários manipulem grande volume de dados e sua principal desvantagem está no seu alto custo, pois exige ambiente especial para mainframes e soluções centralizadas.

• Sistemas de Computador Pessoal: fazem seus processamentos sozinhos e, com isso, trabalham em sistema stand-alone. No começo esse processamento era bastante limitado, porém, com a evolução do hardware, tem-se hoje PCs com grande capacidade de processamento. Utilizam o padrão Xbase e, em se tratando de SGBDs, funcionam como hospedeiros e terminais. Desta forma, possuem um único aplicativo a ser executado na máquina e sua principal vantagem é a simplicidade.

• Banco de Dados Cliente-Servidor: nessa arquitetura, o cliente (front_end) executa as tarefas do aplicativo fornecendo a interface do usuário (tela e processamento de entrada e saída). O servidor (back_end) executa as consultas no DBMS e retorna os resultados ao cliente. Embora sendo uma arquitetura bastante popular, são necessárias soluções sofisticadas de software que possibilitem: o tratamento de transações, as confirmações de transações (commits), desfazer transações (rollbacks), linguagens de consultas (stored procedures) e gatilhos (triggers). A principal vantagem dessa arquitetura é a divisão do processamento entre dois sistemas, o que reduz o tráfego de dados na rede. (Ver Figura 2.8)

• Banco de Dados Distribuídos (N camadas): como se pode observar na Figura 2.9, a informação, nessa arquitetura, está distribuída em diversos servidores. Cada servidor atua como no sistema cliente-servidor, porém as consultas oriundas dos aplicativos são feitas para qualquer servidor indistintamente. Caso a informação solicitada seja mantida por outro servidor ou servidores, o sistema encarrega-se de obter a informação necessária, de maneira transparente para o aplicativo, que passa a atuar consultando a rede, independente de conhecer seus servidores. As bases de dados corporativas, em que o volume de informação

é muito grande e, por isso, deve ser distribuído em diversos servidores são exemplos típicos. Porém, não é

dependente de aspectos lógicos de carga de acesso aos dados, ou de base de dados fracamente acopladas, em que uma informação solicitada vai sendo coletada numa propagação da consulta numa cadeia de servidores.

A existência de diversos programas aplicativos consultando a rede para acessar os dados necessários é a característica básica, porém, sem o conhecimento explícito de quais servidores dispõem desses dados.

Sistemas de Banco de Dados

Introdução à Modelagem Conceitual

Unidade I

Figura 2.8. Arquitetura Cliente-Servidor

Unidade I Figura 2.8. Arquitetura Cliente-Servidor Fonte: Produzido pelo autor. Figura 2.9. Arquitetura

Fonte: Produzido pelo autor.

Figura 2.9. Arquitetura Distribuída N Camadas

pelo autor. Figura 2.9. Arquitetura Distribuída N Camadas Fonte: Adaptado de Silberschatz (2006) 4. Classificação

Fonte: Adaptado de Silberschatz (2006)

4. Classificação dos SGBDs

O principal critério utilizado para classificar um SGBD é o modelo de dados no qual é baseado. A grande maioria dos SGBDs atuais são baseados no modelo relacional, alguns em modelos conceituais e outros em modelos orientados a objetos. Outras classificações possíveis.

Quanto aos usuários: um SGBD pode ser monousuário, comumente utilizado em computadores pessoais ou multi-usuários, utilizado em estações de trabalho, minicomputadores e máquinas de grande porte.

Quanto à localização: um SGBD pode ser localizado ou distribuído; se ele for localizado, então todos os dados estarão em uma só máquina (ou em um único disco); se distribuído, os dados estarão distribuídos por diversas máquinas (ou diversos discos).

Quanto ao ambiente: ambiente homogêneo é o ambiente composto por um único SGBD e um ambiente heterogêneo é o ambiente composto por diferentes SGBDs.

Pós-Graduação a Distância

Introdução à Modelagem Conceitual

Unidade I

5. Exemplos de Sistemas Gerenciadores de Banco de Dados

Existem, atualmente no mercado, vários aplicativos que exercem a função de Sistemas Gerenciadores de Banco de Dados. A seguir, apresentamos alguns exemplos.

dBASE: é um aplicativo lançado pela Ashton-Tate e posteriormente adquirido pela Borland. Teve versões para DOS e Windows, trabalhava com gerenciamento de arquivos planos baseados em listas invertidas e possuía uma linguagem de programação própria para desenvolvimento de aplicações. A partir da versão 7, os direitos foram vendidos pela Borland.

Paradox: teve versões para DOS e hoje possui apenas versões para Windows. Possui ambiente integrado de desenvolvimento para criação de aplicativos e seus direitos de produção foram vendidos para a Corel.

DataFlex: teve versões para DOS e Windows e é popular para ambiente Unix. Hoje é comercializado com o nome de Visual Data Flex e possui ambiente integrado para o desenvolvimento de aplicações.

FoxBase/FoxPro: é um aplicativo concorrente do dBase, com total compatibilidade em termos de arquivos e programas-fontes. Possui recursos adicionais como a capacidade de pré-compilação dos códigos-fontes para melhorar o desempenho. Hoje, se chama Visual FoxPro após a aquisição pela Microsoft da Fox Software (produtora original).

Access: é um aplicativo que, por possuir ambiente integrado, permite a criação e gerenciamento do banco de dados, desenvolvimento de aplicações e geração de relatórios. Sua linguagem de programação deriva do Visual Basic. Para microcomputadores do ambiente Windows é padrão em banco de dados.

Oracle: é o primeiro em Banco de Dados Corporativos (cliente/servidor) possuindo grande variedade de distribuições (para Macintosh, Windows, Linux, FreeBSD, Unix) e para computadores de grande porte. É padrão SQL com uma linguagem própria para desenvolvimento de aplicações.

Interbase: teve uma versão liberada como Open Source e foi incluído, pela Borland, nas suas ferramentas de desenvolvimento (Delphi, C++Builder, JBuider).

MS-SQL Server: as versões atuais são independentes e operam exclusivamente sobre Windows. Foi produzido pela Microsoft. Inicialmente era uma versão especial do Sybase.

Sybase SQL Anywhere: as aplicações para esse banco de dados são desenvolvidas com o PowerBuilder. No mercado, seu concorrente corporativo é o Oracle.

MySQL: além de gratuito, possui versões para Windows, Solaris, Unix, FreeBSD, Linux. Usado principalmente para desenvolvimento WEB como servidor de dados para comércio eletrônico.

PostgreSQL: além de ser gratuito, tem boa aceitação. Foi concebido para rodar em Linux e possui versões para Windows. É, principalmente, usado para comércio eletrônico, juntamente com a linguagem PHP.

Informix: aplicativo comercializado pela IBM. Possui boa escalabilidade e desempenho.

BD2: aplicativo produzido pela IBM, nasceu nos ambientes de grande porte, sendo posteriormente portado para plataformas mais simples (microcomputadores).

Firebird: aplicativo nascido de uma iniciativa da Borland em abrir o código do InterBase 6. Este sistema é open source e esbanja versatilidade e robustez. Possui recursos de trigger, store procedures e transações concorrentes.

Sistemas de Banco de Dados

Introdução à Modelagem Conceitual

Unidade I

Capítulo 3 – Modelagem de Dados Utilizando o MER

I Capítulo 3 – Modelagem de Dados Utilizando o MER Uma entidade dever ter atributos que

Uma entidade dever ter atributos que necessitam ser conhecidos do ponto de vista dos negócios ou então não é uma entidade no escopo dos requisitos do negócio.

1. O Modelo Entidade-Relacionamento (MER)

O Modelo Entidade-Relacionamento (MER) foi definido por Peter Chen, , em 1976, e teve como base a teoria relacional

criada por E.F.Codd (1970). Segundo Chen, a visão de uma dada realidade baseia-se no relacionamento entre entidades, que retratam os fatos que governam essa mesma realidade, e que cada um (entidade ou relacionamento) pode possuir atributos (qualificadores dessa realidade).

É um modelo de dados conceitual de alto nível, cujos conceitos foram projetados para estar o mais próximo possível da

visão que o usuário tem dos dados, não se preocupando em representar como esses dados estarão realmente armazenados. Baseia-se na percepção de um mundo real que consiste em uma coleção de objetos básicos, denominados entidades, e de relações entre esses objetos.

O MER é utilizado principalmente durante o processo de projeto de banco de dados e é, atualmente, a técnica mais difundida, chegando a confundir-se com a própria modelagem de dados.

A Figura 3.1 faz uma descrição simplificada do processo de projeto de um banco de dados.

1.1. Características do MER

O modelo ER apresenta as seguintes características.

Expressividade: suporta relacionamentos n-ários; inclui os três mecanismos de abstração: classificação, agregação e generalização.

Simplicidade: possui uma riqueza de conceitos e com isso se torna uma poderosa ferramenta para a descrição da realidade. Não é um modelo muito simples, especialmente no que diz respeito aos conceitos de cardinalidade, cobertura de generalização e identificação. Uma solução é produzir diagramas ER em diferentes níveis de detalhe.

Minimalidade: nenhum conceito do modelo pode ser descrito em termos dos demais, com exceção dos atributos compostos. O fato de a mesma realidade poder ser modelada de diferentes maneiras não invalida a minimalidade do modelo.

Formalidade: possui o necessário grau de formalidade, uma vez que cada um de seus conceitos possui uma interpretação única, precisa e bem-definida.

Representação gráfica: todos os seus conceitos possuem um símbolo gráfico associado, por isso, é um modelo graficamente completo. Os diagramas ER são fáceis de serem entendidos pelos usuários.

Introdução à Modelagem Conceitual

Unidade I

2. Uma aplicação

A Figura 3.1 descreve uma base de dados COMPANHIA, que será utilizada para ilustrar o processo de projeto de base

de dados. São listados os requisitos da base de dados e criado o seu esquema conceitual passo a passo ao mesmo tempo em que são introduzidos os conceitos de modelagem usando o MER.

A base de dados COMPANHIA armazena os dados dos empregados, departamentos e projetos. Supõe-se que após a

Obtenção e Análise dos Requisitos, os projetistas da base de dados produziram a seguinte descrição do minimundo –

parte da companhia a ser representada na base de dados.

• A companhia é organizada em departamentos. Cada departamento tem um nome, um número e um empregado que o gerencia. Armazena-se a data de início em que o empregado começou a gerenciar o departamento. Um departamento pode ter diversas localizações.

• Um departamento controla inúmeros projetos, sendo que cada um tem um nome, um número e uma localização.

• Do empregado armazena-se o nome, número do seguro social, endereço, salário, sexo e a data de nascimento. Todo empregado é associado a um departamento, mas pode trabalhar em diversos projetos, que não são necessariamente controlados pelo mesmo departamento. Armazena-se, também, o número de horas que o empregado trabalha em cada projeto. Mantém-se, ainda, a indicação do supervisor direto de cada projeto.

• Os dependentes de cada empregado são armazenados com o propósito de garantir os benefícios do seguro. Para cada dependente será armazenado o nome, sexo, data de nascimento e o relacionamento com o empregado.

Figura 3.1: Esquematização da Modelagem de Dados usando o MER

Mini-Mundo Obtenção e Análise Requisitos Requisitos da Base de Dados Projeto Conceitual Modelo Conceitual
Mini-Mundo
Obtenção e Análise Requisitos
Requisitos da Base de Dados
Projeto Conceitual
Modelo Conceitual (Alto-Nível)
Mapeamento do Modelo de Dados
Esquema Conceitual (SGBD específico)
Projeto Físico
Esquema Interno
Banco de Dados
Fonte: Adaptado de Silberschatz (2006).
Conforme o SGBD
Comum a todos os tipos de SGBD
Pós-Graduação a Distância

Sistemas de Banco de Dados

Introdução à Modelagem Conceitual

Unidade I

3. Entidades e Atributos

O objeto básico tratado pelo modelo ER é a entidade, que pode ser definida como um objeto do mundo real, concreto ou abstrato e que possui existência independente.

Cada entidade possui um conjunto particular de propriedades que a descreve, denominado atributos. Para cada atributo existe um conjunto de valores permitidos, que é chamado de domínio desse atributo. Um atributo pode ser dividido em diversas partes menores com significado independente entre si, recebendo o nome de atributo composto. Um atributo que não pode ser subdividido é chamado de atributo simples ou atômico.

O atributo que pode assumir apenas um determinado valor em uma determinada instância é denominado atributo

simplesmente valorado, enquanto que um atributo que pode assumir diversos valores em uma mesma instância é denominado multivalorado. Um atributo que é gerado a partir de outro é chamado de atributo derivado.

4. Tipos Entidade, Conjunto de Valores, Atributo Chave

Um banco de dados costuma conter grupos de entidades que são similares, possuindo os mesmos atributos, porém, cada entidade conta com seus próprios valores para cada atributo. Esse conjunto de entidades similares forma tipo entidade. Cada tipo entidade é identificado por seu nome e pelo conjunto de atributos que definem suas propriedades. A descrição do tipo entidade é chamada de esquema do tipo entidade, onde são especificados o nome do tipo entidade, o nome de cada um de seus atributos e qualquer restrição que incida sobre as entidades.

5. Relacionamentos

5.1. Tipos de Relacionamento

Um tipo relacionamento R entre n entidades E 1 , E 2 ,

tipo. Em outras palavras, cada instância de relacionamento r 1 em R é uma associação de entidades. Isso significa que essas entidades estão relacionadas de alguma forma no minimundo.

, E n é um conjunto de associações possíveis entre entidades desse

A Figura 3.2 mostra um exemplo entre dois tipos entidade (empregado e departamento) e o relacionamento entre eles

(trabalha para). Repare que para cada relacionamento participa apenas uma entidade de cada tipo entidade, porém, uma entidade pode participar de mais de um relacionamento.

Figura 3.2. Exemplo de um Relacionamento Binário

Empregado Trabalha Para Departamento R 1 E 1 R E 2 D 2 1 R
Empregado
Trabalha Para
Departamento
R
1
E
1
R
E
2
D
2
1
R
E
3
3
D
2
E
R
4
4
D
E
R
3
5
5
E
6
R
6

Pós-Graduação a Distância

Introdução à Modelagem Conceitual

Unidade I

5.2. Grau de um Relacionamento

O grau de um tipo relacionamento é o número de tipos entidade que participam do tipo relacionamento. No exemplo da Figura 3.2, temos um relacionamento binário. O grau de um relacionamento é ilimitado, porém, a partir do grau 3, a compreensão e a dificuldade de se desenvolver a relação corretamente se tornam extremamente complexas.

Um exemplo de um tipo de relacionamento ternário é Fornece para, ilustrado na Figura 3.3. Cada instância de relacionamento R 1 associa três entidades – um fornecedor F, uma peça E e um projeto P – onde o fornecedor F fornece a peça E para o projeto P. Podem existir tipos de relacionamento de qualquer grau, porém é mais freqüente encontrar o tipo de relacionamento de grau dois.

5.3. Relacionamentos como Atributos

Algumas vezes é conveniente pensar em um relacionamento como um atributo. Considere o exemplo da Figura 3.2. Podemos pensar departamento como sendo um atributo da entidade empregado, ou empregado, como um atributo multivalorado da entidade departamento. Se uma entidade não possuir existência muito bem definida, talvez seja mais interessante para a coesão do modelo lógico que ela seja representada como um atributo.

Figura 3.3. Exemplo de um Relacionamento Ternário

Peças E 1 E 2 Fornecer para E 3 Projeto R 1 E 4 R
Peças
E
1
E
2
Fornecer para
E
3
Projeto
R
1
E
4
R
E
2
5
P
1
R
E
3
6
P
R
2
4
P
R
3
Fornecedor
5
R
6
F
1
F
2

5.4. Nomes de Papéis e Relacionamentos Recursivos

Cada tipo entidade que participa de um tipo relacionamento desempenha um papel particular no relacionamento. O nome do papel representa o papel que uma entidade de um tipo entidade participante desempenha no relacionamento. No exemplo da Figura 3.2, nós temos o papel empregado ou trabalhador para o tipo entidade EMPREGADO e o papel departamento ou empregador para a entidade DEPARTAMENTO.

Nomes de papéis não são necessariamente importantes quando todas as entidades participantes desempenham papéis diferentes. Algumas vezes, o papel torna-se essencial para distinguir o significado de cada participação. Isso é muito comum em “relacionamentos recursivos”.

Um relacionamento recursivo é um relacionamento entre entidades do mesmo tipo entidade, conforme ilustrado na Figura

3.4.

Sistemas de Banco de Dados

Introdução à Modelagem Conceitual

Unidade I

Na Figura 3.4, temos um relacionamento entre o tipo entidade EMPREGADO, onde um empregado pode supervisionar outro empregado e um empregado pode ser supervisionado por outro empregado.

Figura 3.4. Um Relacionamento Recursivo Supervisiona Empregado R 1 E 1 R 2 E 2
Figura 3.4. Um Relacionamento Recursivo
Supervisiona
Empregado
R 1
E 1
R 2
E 2
R 3
E 3
R
E 4
4
E 5
R 5
E 6
R 6
Supervisiona
Supervisionando

6. Refinando o Projeto de Entidade-Relacionamento

6.1. Tipos Entidades Fracas

Em alguns casos, alguns tipos entidade podem não ter um atributo chave por si só. Isso implica que não poderemos distinguir algumas entidades porque as combinações dos valores de seus atributos podem ser idênticas. Esses tipos entidade são chamados entidades fracas. As entidades desse tipo precisam estar relacionadas com uma entidade pertencente ao tipo entidade proprietária. Esse relacionamento é chamado de relacionamento identificador.

Na Figura 3.5, o tipo entidade DEPENDENTE é uma entidade fraca uma vez que não possui um método de identificar uma entidade única. O EMPREGADO não é uma entidade fraca uma vez que possui um atributo para identificação (atributo chave).

O número do CPF de um empregado pode identificar um único empregado, porém um dependente de 5 anos de idade não possui necessariamente um documento como esse. Dessa forma, essa entidade é um tipo entidade fraca.

Figura 3.5. Exemplo de um Relacionamento com uma Entidade Fraca

Empregado Possui Dependente Dependente R D E 1 1 1 R E D 2 2
Empregado
Possui Dependente
Dependente
R
D
E
1
1
1
R
E
D
2
2
2
E
R
3
3
D
3

Um tipo entidade fraca possui uma chave parcial que, juntamente com a chave primária da entidade proprietária, forma uma chave primária composta.

No exemplo da Figura 3.5 a chave primária do EMPREGADO pode ser o CPF. A chave parcial do DEPENDENTE pode ser o seu nome, pois dois irmãos não podem ter o mesmo nome. Desse modo, a chave primária desta entidade fica sendo o CPF do pai ou da mãe mais o nome do dependente.

Pós-Graduação a Distância

Introdução à Modelagem Conceitual

Unidade I

6.2. Atributos em Tipos de Relacionamentos

Os tipos de relacionamento também podem ter atributos da mesma maneira que os tipos de entidades. Exemplificando, tomemos a situação representada pela Figura 3.6 e acrescentemos a necessidade de representar a data em que um EMPREGADO começou a gerenciar um DEPARTAMENTO por meio de um atributo Data_Início para o tipo de relacionamento GERÊNCIA.

Figura 3.6. Exemplo de um Relacionamento

Empregado E 1 Gerência Departamento E 2 R D 1 1 E 3 R D
Empregado
E
1
Gerência
Departamento
E
2
R
D
1
1
E
3
R
D
E
2
2
4
R
E
3
D
5
3
E
6

Nesse caso, é possível perceber que atributos de tipos de relacionamento 1:1 ou 1:N podem ser incluídos como atributos de um dos tipos de entidades participantes. Assim, o atributo Data_Início para o tipo de relacionamento GERÊNCIA pode ser um atributo tanto de EMPREGADO quanto de DEPARTAMENTO embora, conceitualmente, ele pertença ao relacionamento GERÊNCIA. Isso ocorre porque GERÊNCIA é um relacionamento 1:1, uma vez que toda entidade DEPARTAMENTO ou EMPREGADO participam em apenas uma instância de relacionamento e, dessa forma, o valor do atributo Data_Início pode ser representado em qualquer uma das entidades participantes.

No caso de um tipo de relacionamento 1:N, um atributo de relacionamento pode somente ser colocado no tipo de entidade que está do lado N do relacionamento. Isso pode ser visto na Figura 3.2, pois se o relacionamento TRABALHA- PARA tiver um atributo Data_Início, indicando quando um empregado começou a trabalhar para um DEPARTAMENTO, esse atributo pode ser colocado como atributo de EMPREGADO. Isso ocorre porque o relacionamento é 1:N de modo que cada entidade EMPREGADO participa apenas uma única vez em uma instância de TRABALHA-PARA.

Uma vez que o valor de um atributo é determinado pela combinação das entidades participantes em uma instância de relacionamento, e não apenas por uma das entidades, então o atributo deve ser especificado como um atributo de relacionamento. Esse é o caso de atributos de tipos de relacionamentos M:N, porque as entidades dos tipos de entidades participantes podem participar em inúmeras instâncias de relacionamento.

Exemplificando, tomemos a situação descrita na Figura 3.2 e acrescentemos a necessidade de incluir o atributo Horas_ Trabalhadas do relacionamento M:N TRABALHA-PARA. O número de horas que um empregado trabalha em um projeto

é determinado pela combinação empregado-projeto e não separadamente.

6.3. Modelo Entidade-Relacionamento Estendido (ERE)

Os conceitos do modelo Entidade-Relacionamento, discutidos anteriormente, são suficientes para representar logicamente

a maioria das aplicações de banco de dados. Porém, com o surgimento de novas aplicações, surgiu também a necessidade de novas semânticas para a modelagem de informações mais complexas.

O modelo Entidade-Relacionamento Estendido (ERE) visa fornecer esta semântica para permitir a representação de informações complexas. É importante frisar que, embora o modelo ERE trate classes e subclasses, ele não possui a mesma semântica de um modelo orientado a objetos.

Sistemas de Banco de Dados

Introdução à Modelagem Conceitual

Unidade I

O modelo ERE engloba todos os conceitos do modelo E-R mais os conceitos de subclasse, superclasse, generalização, especialização e o de herança de atributos.

6.3.1. Subclasses, Superclasses e Especializações

O primeiro conceito do modelo ERE, que será abordado, é o de subclasse de um tipo entidade.

Como visto anteriormente, um tipo entidade é utilizado para representar um conjunto de entidades do mesmo tipo. Em muitos casos, um tipo entidade possui diversos subgrupos adicionais de entidades que são significativas e precisam ser representadas explicitamente, devido ao seu significado, à aplicação de banco de dados. Considere o seguinte exemplo:

Para um banco de dados de uma empresa temos o tipo entidade empregado, o qual possui as seguintes características:

nome, RG, CPF, número funcional, endereço completo (rua, número, complemento, CEP, bairro, cidade), sexo, data de nascimento e telefone (ddd e número); caso o(a) funcionário(a) seja um(a) engenheiro(a), então deseja-se armazenar as seguintes informações: número do CREA e especialidade (Civil, Mecânico, Eletrônico); caso o(a) funcionário(a) seja um(a) secretário(a), então se deseja armazenar as seguinte informações: qualificação (bi ou trilíngue) e os idiomas em que possui fluência verbal e escrita.

Se as informações número do CREA, especialidade, tipo e idiomas forem representados diretamente no tipo entidade empregado estaremos representando informações de um conjunto limitado de entidades empregado para os todos os funcionários da empresa. Nesse caso, podemos criar duas subclasses do tipo entidade empregado: engenheiro e secretária, as quais irão conter as informações acima citadas. Além disto, engenheiro e secretária podem ter relacionamentos específicos.

Uma entidade não pode existir meramente como componente de uma subclasse. Antes de ser componente de uma subclasse, uma entidade deve ser componente de uma superclasse. Isto leva ao conceito de herança de atributos; ou seja, a subclasse herda todos os atributos da superclasse. Isso porque a entidade de subclasse representa as mesmas características de uma mesma entidade da superclasse. Uma subclasse pode herdar atributos de superclasses diferentes. Uma representação diagramática do exemplo mencionado é ilustrada na Figura 3.7.

Figura 3.7. Representação de Superclasse e Subclasses

Nome
Nome
N o Funcional
N o Funcional
Dt. Nascimento
Dt. Nascimento
Sexo
Sexo
Endereço
Endereço
Subclasses Nome N o Funcional Dt. Nascimento Sexo Endereço CPF RG Empregado Função d N o
CPF
CPF
RG
RG

Empregado

Função

d
d
N o Registro Qualificação Engenheiro Engenheiro Especialização Idiomas
N o Registro
Qualificação
Engenheiro
Engenheiro
Especialização
Idiomas

6.3.2. Especialização

Especialização é o processo de definição de um conjunto de classes de um tipo entidade; esse tipo entidade é chamado de superclasse da especialização. O conjunto de subclasses é formado com base em alguma característica que distinga as entidades entre si.

No exemplo da Figura 3.7, temos uma especialização, que podemos chamar de função. Veja agora no exemplo da Figura 3.8, temos a entidade empregado e duas especializações.

Pós-Graduação a Distância

Introdução à Modelagem Conceitual

Unidade I

Figura 3.8. Duas Especializações para Empregado: Função e Categoria Salarial

Categoria Função Salarial d Empregado d Engenheiro Secretária Horista Mensalista
Categoria
Função
Salarial
d
Empregado
d
Engenheiro
Secretária
Horista
Mensalista

Como visto anteriormente, uma subclasse pode ter relacionamentos específicos com outras entidades ou com a própria entidade, que é a sua superclasse. Veja o exemplo da Figura 3.9.

Figura 3.9. Relacionamentos entre Subclasses e Entidades

N Empregado Projeto É liderado Função N S d Lidera N Engenheiro Participa
N
Empregado
Projeto
É liderado
Função
N
S
d
Lidera
N
Engenheiro
Participa

É desenvolvido por

O processo de especialização nos permite:

• definir um conjunto de subclasses de um tipo entidade;

• associar atributos específicos adicionais para cada subclasse;

• estabelecer tipos relacionamentos específicos entre subclasses e outros tipos entidades.

6.3.3. Generalização

A generalização pode ser pensada como um processo de abstração reverso ao da especialização, no qual são suprimidas

as diferenças entre diversos tipos entidades, identificando suas características comuns e generalizando essas entidades

em uma superclasse.

Sistemas de Banco de Dados

Introdução à Modelagem Conceitual

Unidade I

Figura 3.10. Tipos Entidades Engenheiro e Secretária

I Figura 3.10. Tipos Entidades Engenheiro e Secretária Figura 3.11. Generalização Empregado para os Tipos

Figura 3.11. Generalização Empregado para os Tipos Entidades Engenheiro e Secretária

Empregado para os Tipos Entidades Engenheiro e Secretária É importante destacar que existe diferença semântica

É importante destacar que existe diferença semântica entre a especialização e a generalização. Na especialização, podemos notar que a ligação entre a superclasse e as subclasses é feita por meio de um traço simples, indicando participação parcial por parte da superclasse. Analisando o exemplo da Figura 3.9, é observado que um empregado não é obrigado a ser um engenheiro ou uma secretária. Na generalização, podemos notar que a ligação entre a superclasse e as subclasses

é feita por intermédio de um traço duplo, indicando participação total por parte da superclasse. Analisando o exemplo da Figura 3.10, é observado que um empregado é obrigado a ser um engenheiro ou uma secretária.

A letra d dentro do círculo que especifica uma especialização ou uma generalização significa disjunção. Uma disjunção

em uma especialização ou generalização indica que uma entidade do tipo entidade que representa a superclasse pode assumir apenas um papel dentro dela. Analisando o exemplo da Figura 3.11 temos duas especializações para a superclasse Empregado, as quais são restringidas por meio de uma disjunção. Nesse caso, um empregado pode ser um engenheiro ou uma secretária e ele pode ser horista ou mensalista.

Além da disjunção, podemos ter um overlap, representado pela letra o. No caso do “overlap”, uma entidade de uma superclasse pode ser membro de mais que uma subclasse em uma especialização ou generalização. Analise a generalização no exemplo da Figura 3.12. Suponha que uma peça fabricada em uma tornearia pode ser manufaturada ou torneada, ou ainda, pode ter sido manufaturada e torneada.

Pós-Graduação a Distância

Introdução à Modelagem Conceitual

Unidade I

Figura 3.12. Uma Generalização com “Overlap”

Unidade I Figura 3.12. Uma Generalização com “Overlap” 6.3.4. “Lattice” ou Múltipla Herança Uma subclasse

6.3.4. “Lattice” ou Múltipla Herança

Uma subclasse pode ser definida por meio de um “lattice”, ou múltipla herança, ou seja, ela pode ter diversas superclasses, herdando características de todas. Tomemos como base a situação de que uma construtora possui diversos funcionários, que podem ser engenheiros ou secretárias. Um funcionário pode também ser assalariado ou horista. Todo gerente de departamento da construtora deve ser um engenheiro e assalariado.

O modelo lógico da expressão acima tem o seguinte formato (Figura 3.13):

Figura 3.13. Um “Lattice” com a Subclasse Gerente Compartilhada

3.13. Um “Lattice” com a Subclasse Gerente Compartilhada Nesse caso, então, um gerente será um funcionário

Nesse caso, então, um gerente será um funcionário que, além de possuir as características próprias de Gerente, herdará as características de Engenheiro e de Mensalista.

7. Diagrama Entidade-Relacionamento

O Diagrama Entidade-Relacionamento (DER) é composto por um conjunto de objetos gráficos que visa representar

todos os objetos do modelo Entidade Relacionamento, tais como entidades, atributos, atributos chaves, relacionamentos,

restrições estruturais etc.

O diagrama ER oferece uma visão lógica do banco de dados, fornecendo um conceito mais generalizado de como estão estruturados os dados de um sistema.

Sistemas de Banco de Dados

Introdução à Modelagem Conceitual

Unidade I

7.1. Tipos de Notação do Modelo Entidade-Relacionamento

Várias formas de notação de um MER foram desenvolvidas. Entre elas podemos destacar:

• ER – Peter Chen

• UML – OMG (Grady, Booch, Rumbaugh)

• IE (Information Engineering) – J. Martin

• IDEF1X (US Federal Governament)

Apesar de todas se destinarem, em suma, à mesma finalidade, a notação mais utilizada ainda é a ER, proposta por Peter Chen.

Os elementos gráficos que compõem o Diagrama Entidade-Relacionamento (DER), proposto por Chen (1976), são:

• Retângulos: conjuntos de entidades.

• Linhas duplas: conjuntos de entidades fracas.

• Elipses: atributos. Os atributos da chave primária são sublinhados.

• Losangos: conjuntos de relacionamentos. Linhas duplas representam conjuntos de relacionamentos envolvidos com entidades fracas.

• Linhas: unem atributos aos conjuntos de entidades e esses aos conjuntos de relacionamentos.

• Linhas direcionadas: a seta indica a cardinalidade um.

• Elipses duplas: atributos multivalorados. Linhas duplas indicam participação total de uma entidade em um conjunto de relacionamentos.

A Figura 3.14 apresenta os objetos que compõem o diagrama E-R.

Apresentamos, na Figura 3.15, um DER para o esquema da base de dados COMPANHIA.

Mapeando a descrição apresentada na Figura 3.14, teremos:

• Os tipos de entidades tais como EMPREGADO, DEPARTAMENTO e PROJETO são mostrados em retângulos.

• Os tipos de relacionamentos tais como TRABALHA-PARA, GERENCIA, CONTROLA e TRABALHA-EM são mostrados em losangos interligados a tipos de entidades participantes.

• Os atributos são mostrados em elipses conectadas a tipos de entidades ou relacionamentos.

• Os componentes de um atributo composto são também representados em elipses, porém conectados ao atributo ao qual eles pertencem (atributo Nome de EMPREGADO).

• Os atributos multivalorados são denotados em elipses com linhas duplas (atributo Localização de DEPARTAMENTO).

• Os atributos-chaves são representados de forma sublinhada.

• Os atributos derivados são representados em elipses com linhas tracejadas (atributo Número De Empregados de DEPARTAMENTO).

Pós-Graduação a Distância

Introdução à Modelagem Conceitual

Unidade I

• Os tipos de entidades-fracas são distinguidos por retângulos com linhas duplas e os relacionamentos de identificação, por losangos com linhas duplas (tipo de entidade-fraca DEPENDENTE e tipo de relacionamento de identificação DEPENDENTE-DE).

Figura 3.14. Objetos que Compõem o Diagrama ER

Figura 3.14. Objetos que Compõem o Diagrama ER • A chave-parcial de um tipo de entidade-fraca

• A chave-parcial de um tipo de entidade-fraca é sublinhada com linha tracejada.

• São mostradas as razões de cardinalidade para cada tipo de relacionamento binário. A razão de cardinalidade de DEPARTAMENTO: EMPREGADO em GERÊNCIA é 1:1, para DEPARTAMENTO: EMPREGADO em TRABALHA-PARA é 1:N e M:N para TRABALHA em.

• As restrições de participação parcial são especificadas por linhas simples. As linhas paralelas denotam participação total (dependência existencial).

• São apresentados os nomes de papéis para o tipo de relacionamento SUPERVISIONA porque o tipo de entidade EMPREGADO ocupa dois papéis nesse relacionamento.

Na Figura 3.15 é apresentado o mesmo esquema da Figura 3.16, porém com a utilização da notação alternativa para ilustrar as restrições estruturais de tipos de relacionamentos.

Introdução à Modelagem Conceitual

Unidade I

Figura 3.15. – DER para o Esquema Companhia

Unidade I Figura 3.15. – DER para o Esquema Companhia Figura 3.16. – DER para o

Figura 3.16. – DER para o Esquema Companhia com Notação Alternativa

Sistemas de Banco de Dados
Sistemas de Banco de Dados

Unidade II

Pós-Graduação a Distância

Sistemas de Banco de Dados:

conceitos e arquiteturas

Sistemas de Banco de Dados: conceitos e arquiteturas Capítulo 4 – Modelo de Dados Relacional Hoje

Capítulo 4 – Modelo de Dados Relacional

e arquiteturas Capítulo 4 – Modelo de Dados Relacional Hoje em dia o termo banco de

Hoje em dia o termo banco de dados é bastante popular em diversas áreas de atuação. Com o aumento da utilização de computadores na manipulação de dados que envolvem diversas aplicações, os bancos de dados estão sendo desenvolvidos e aplicados nas diferentes áreas que envolvem o comércio, a indústria e a pesquisa acadêmica entre outras.

1. Introdução

Segundo Silberschatz (2006), Modelo de Dados é uma coleção de ferramentas conceituais para descrever dados, relações de dados, semântica de dados e restrições de consistência, constituindo-se em uma maneira de descrever o projeto de um banco de dados nos seus vários níveis de abstração.

As bases do modelo relacional foram lançadas por Edgar Codd, nos anos 1970, e começou a ser realmente utilizado nas empresas a partir de 1987, por meio do SGBDs, tendo como finalidade representar os dados como uma coleção de relações, onde cada relação é representada por uma tabela. O conceito principal vem da teoria dos conjuntos (álgebra relacional) atrelado à idéia de que não é relevante ao usuário saber onde os dados estão nem como os dados estão.

Quando uma relação é pensada como uma tabela de valores, cada linha nessa tabela representa uma coleção de dados relacionados. Esses valores podem ser interpretados como fatos descrevendo uma instância de uma entidade ou de um relacionamento. O nome da tabela e das colunas são utilizados para facilitar a interpretação dos valores armazenados em cada uma de suas linhas. Todos os valores em uma coluna são necessariamente do mesmo tipo.

Na terminologia do modelo relacional temos:

• cada tabela é chamada de relação;

• cada linha de uma tabela é chamada de tupla;

cada coluna é denominada atributo;

• o tipo de dado que descreve cada coluna é chamado de domínio;

• o grau da relação é o número do atributos da relação.

Sistemas de Banco de Dados

Sistemas de Banco de Dados: conceitos e arquiteturas

Unidade II

Segundo Takai (2005), quando uma relação é vista como uma tabela de valores, cada linha representa uma coleção de valores relacionados. Esses valores podem ser interpretados como um fato que descreve uma entidade ou uma instância de relacionamento. O nome da tabela e os nomes das colunas são usados para ajudar a interpretar o significado dos valores em cada linha da tabela.

Exemplificando, na Figura 4.1, a primeira tabela é chamada ESTUDANTE porque cada linha representa o fato sobre uma particular entidade estudante. Os nomes das colunas – Nome, Número, Classe, Departamento – especificam como interpretar os valores em cada linha, baseando-se nas colunas em que cada um se encontra. Todos os valores de uma coluna são, normalmente, do mesmo tipo.

Figura 4.1. Exemplo de uma base de dados relacional

ESTUDANTE

Nome

Matrícula

Classe

Departamento

 
 

José

3217

1

DCT

Ana Maria

2325

2

DCT

Carla

4112

1

ENG

CURSO

Nome

Código

Créditos

Departamento

 

Banco de Dados I

BD1322

4

DCT

Redes Neurais

RN1132

4

DCT

Banco de Dados II

BD1323

4

DCT

Cáculo I

CA1011

4

ENG

SEÇÃO

Número

Curso

Semestre

Ano

Professor

 

11

RN1132

1

2007

Antônio

13

BD1322

1

2007

Pedro

13

BD1323

2

2007

Angélica

10

CA1011

1

2006

Pedro

Tomemos como exemplo de uma relação esquema R de grau 4, que descreve estudantes universitários:

R ESTUDANTE (Nome, Número, Classe, Departamento)

Nessa relação-esquema, ESTUDANTE é o nome da relação esquema, que tem 4 atributos. Podemos especificar alguns domínios para cada atributo da relação ESTUDANTE:

dom(Nome)=Nomes

dom(Matrícula)=Número da matrícula dos alunos

dom(Classe)=Número de identificação das turmas

dom(Departamento)=Código relativo ao departamento a que os cursos estão vinculados

,

, v n >, onde cada valor v i , 1 i n, é um elemento

do dom(A i ) ou um valor especial null. São utilizados, com freqüência, os termos intenção da relação para o esquema R e extensão da relação para a instância r(R).

Uma relação r 1 da relação esquema R(A 1 , A 2 ,

, t m }. Cada tupla t é uma lista ordenada de n valores t=<v 1 , v 2 ,

A n ), também denotada por r(R), é um conjunto de tuplas r={ t 1 , t 2 ,

1.1. Atributos-chave de uma relação

Uma relação é definida como um conjunto de tuplas. Pela definição, todos os elementos de um conjunto são distintos. Assim, todas as tuplas de uma relação também são distintas. Isso significa que nenhuma tupla pode ter a mesma

1 Também chamada de instância de relação

Pós-Graduação a Distância

Sistemas de Banco de Dados: conceitos e arquiteturas

Unidade II

combinação de valores para todos os seus atributos. Normalmente, existem subconjuntos de atributos de uma relação esquema R com a propriedade de que nenhuma tupla de uma relação r de R tenha a mesma combinação de valores para esses atributos. Suponha que esse subconjunto seja denotado por SC; então, para quaisquer tuplas t 1 e t 2 em r de R, deve valer a regra:

t 1 [SC]

t 2 [SC]

Assim, SC é chamada Super-Chave da relação esquema R. Toda relação tem ao menos uma Super-Chave, que é o conjunto de todos os seus atributos. Uma chave C, de uma relação esquema R, é uma Super-Chave de R com a propriedade adicional de não se poder remover qualquer atributo A de C e continuar a ser Super-Chave de R. Assim, uma chave é uma Super-Chave mínima; uma super-chave da qual não se pode remover qualquer atributo.

Por exemplo, considere a relação ESTUDANTE da Figura 4.1. O conjunto de atributos {Número} é uma Super-Chave de ESTUDANTE, porque se sabe que nenhum estudante irá ter o mesmo número de matrícula, e também é uma chave, pois não se pode remover nenhum atributo. Qualquer conjunto de atributos que inclua Número - por exemplo, {Número, Nome, Anos} - será uma Super-Chave.

No entanto, o conjunto {Número, Nome, Departamento} não é uma chave de ESTUDANTE porque, removendo Nome ou Anos, ou ambos, o conjunto resultante será ainda uma Super-Chave.

A chave deve ser determinada pelo significado dos atributos na relação esquema e deve ser invariante ao tempo. Por exemplo, o atributo Nome da relação ESTUDANTE não pode ser indicado como chave, uma vez que nada garante a não ocorrência de homônimos. Em geral, uma relação esquema pode ter mais que uma chave. Nestes casos, cada chave é chamada chave-candidata. Por exemplo, o esquema da relação ESTUDANTE poderia ter um atributo adicional Código, para indicar o código interno de estudantes na escola. Assim, o esquema teria duas chaves candidatas: Número e Código. É comum designar uma das chaves-candidatas como a Chave-Primária da relação. A indicação no modelo de qual Chave-Candidata é a Chave-Primária é efetuada sublinhando-se os atributos que formam a Chave-Candidata escolhida. Quando uma relação esquema tem muitas Chaves-Candidatas, a escolha da Chave-Primária é arbitrária. No entanto, é sempre melhor escolher a Chave-Primária com o menor número de atributos.

Dicas

O sinônimo é um nome alternativo para a entidade. São muito utilizados quando dois grupos de usuários têm diferentes nomes para o mesmo objeto significante.

2. Restrições do Modelo Relacional

2.1. Restrições em Tipos Relacionamentos

Em geral, os tipos relacionamentos sofrem certas restrições que limitam as possíveis combinações das entidades participantes. Essas restrições são derivadas de restrições impostas pelo estado dessas entidades no minimundo.

A Figura 3.6 representa a situação de que um empregado pode gerenciar apenas um departamento, enquanto que um departamento pode ser gerenciado por apenas um empregado.

Esse tipo de restrição é chamado de cardinalidade. A cardinalidade indica o número de relacionamentos dos quais uma entidade pode participar.

Sistemas de Banco de Dados

Sistemas de Banco de Dados: conceitos e arquiteturas

Unidade II

A cardinalidade apresenta as seguintes possibilidades:

• um para um (1:1);

• um para vários (1:N);

• vários para vários (M:N).

No exemplo da Figura 3.6, a cardinalidade é 1:1, pois cada entidade EMPREGADO pode gerenciar apenas um DEPARTAMENTO e um DEPARTAMENTO pode ser gerenciado por apenas um EMPREGADO.

No exemplo da figura 3.3, no relacionamento FORNECEDOR - Fornece Para - PROJETO, o relacionamento é M:N, pois um fornecedor pode fornecer várias peças para vários projetos.

Uma restrição muito importante é a participação. A participação define a existência de uma entidade por intermédio do relacionamento, podendo ser parcial ou total.

No exemplo da Figura 3.6, a participação do empregado é parcial, pois nem todo EMPREGADO gerencia um DEPARTAMENTO, porém a participação do departamento nesse relacionamento é total, pois todo DEPARTAMENTO necessita ser gerenciado por um EMPREGADO. Dessa forma, todas as entidades do tipo entidade DEPARTAMENTO precisam participar do relacionamento, mas nem todas as entidade do tipo entidade EMPREGADO precisam participar do relacionamento.

Na Figura 3.2, ambas as participações são totais, pois todo EMPREGADO precisa trabalhar em um DEPARTAMENTO e todo DEPARTAMENTO tem que ter EMPREGADOS trabalhando nele. Essas restrições são chamadas de restrições estruturais.

2.2. Restrições de Integridade

As chaves-candidatas de cada relação esquema são especificadas pelas restrições de chave. Essas chaves-candidatas possuem valores que devem ser únicos para todas as tuplas de quaisquer instâncias da relação esquema.

Além da restrição de chave, existem dois outros tipos de restrições no modelo relacional: a integridade de entidade e a integridade referencial.

Na restrição de integridade de entidade nenhum valor da chave-primária pode ser nulo, pois o valor de uma chave-

primária é utilizado para identificar tuplas em uma relação. Por exemplo, se duas ou mais tuplas tiverem o valor null para

a chave primária, não haverá como diferenciar uma tupla da outra.

As restrições de chave e de integridade de entidade aplicam-se apenas a relações individuais.

A restrição de integridade referencial é usada para manter a consistência entre tuplas de duas relações. Informalmente,

a restrição de integridade referencial estabelece que uma tupla de uma relação que se refere à outra relação deve se referir a uma tupla existente naquela relação.

Por exemplo, na Figura 4.2, o atributo NDEP de EMPREGADO indica o número do departamento que cada empregado trabalha. Assim, todos os valores de NDEP nas tuplas da relação EMPREGADO devem pertencer ao conjunto de valores do atributo DNÚMERO da relação DEPARTAMENTO. Para definir formalmente a restrição de integridade referencial, há a necessidade de, antes, definir o conceito de chave-estrangeira (CE). As condições para uma chave-estrangeira, descritas abaixo, especificam uma restrição de integridade referencial entre duas relações esquemas R1 e R2.

Pós-Graduação a Distância

Sistemas de Banco de Dados: conceitos e arquiteturas

Unidade II

Um conjunto de atributos CE na relação esquema R1 será uma chave-estrangeira de R1 se ele satisfizer as seguintes regras:

• os atributos em CE têm o mesmo domínio dos atributos da chave-primária CP da outra relação esquema R 2 . Diz-se que os atributos CE referenciam ou referem-se à relação R 2 ;

• uma CE na tupla t 1 ou tem um valor que ocorre como CP de alguma tupla t 2 de R 2 ou tem o valor null.

No primeiro caso, tem-se t 1 [CE] = t 2 [CP], e diz-se que t 1 referencia ou refere-se à tupla t 2 . Uma base de dados tem muitas relações e possui muitas restrições de integridade referencial. O projetista deve ter um claro entendimento do significado ou papel que os atributos desempenham nas diversas relações esquemas da base de dados para que essas restrições sejam especificadas. Normalmente, as restrições de integridade referencial são derivadas dos relacionamentos entre entidades representadas pelas relações esquemas. Por exemplo, considere a base de dados mostrada na 4.2.

Na relação EMPREGADO, o atributo NDEP refere-se ao departamento em que cada empregado trabalha; desse modo, designa-se NDEP como a chave-estrangeira de EMPREGADO, referenciando a relação DEPARTAMENTO. Isso significa que um valor de NDEP em alguma tupla t1 da relação EMPREGADO deve ter um valor correspondente para a chave-primária da relação DEPARTAMENTO – o atributo DNÚMERO – em alguma tupla t2 da relação DEPARTAMENTO ou o valor de NDEP pode ser null se o empregado não pertencer a nenhum departamento. Na Figura 4.2, a tupla do empregado “John Smith” referencia a tupla departamento de “Pesquisa”, indicando que “John Smith” trabalha para esse departamento. Note que uma chave-estrangeira pode referenciar sua própria relação.

Por exemplo, o atributo NSSSUPER em EMPREGADO refere-se ao supervisor de um empregado, isto é, outro empregado. Pode-se, diagramaticamente, mostrar as restrições de integridade desenhando-se arcos direcionados, partindo da chave- estrangeira para a relação referenciada.

A Figura 4.4 ilustra o esquema apresentado na Figura 4.3, com as restrições de integridade referencial anotadas dessa maneira.

Caso o projetista tenha interesse em manter as restrições válidas para toda a base de dados, essas restrições de integridade deveriam ser especificadas no esquema da base de dados relacional.

No sistema relacional, a linguagem de definição de dados (DDL) deveria fornecer recursos para especificar os vários tipos de restrições tal que o SGDB possa verificá-las automaticamente. Muitos sistemas de gerenciamento de base de dados relacionais permitem restrições de chave e de integridade de entidade, mas alguns não permitem a integridade referencial.

Figura 4.2. Instâncias da base de dados COMPANHIA

EMPREGADO

PNOME

MNOME

SNOME

NSS

DATANASC

ENDEREÇO

SEXO

SALÁRIO

NSSSUPER

NDEP

John

S

Smith

123456789

09-JAN-55

R.

A. 1

M

3000

3334666

5

Franklin

T

Wong

333445555

08-DEZ-45

R.

B. 2

M

4000

888665565

5

Alicia

J

Zelaya

999887777

19-JUL58

Av. C. 3

F

2500

987654321

4

Jeniffer

S

Wallace

987654321

20-JUN-31

Trav. D. 4

F

6300

888664444

4

Ramesh

K

Narayan

666884444

15-SET-52

R.

E. 5

M

3800

333445555

5

Joyce

A

English

453453453

31-JUL-52

R.

F. 6

F

2500

333445565

5

Ahmet

V

Jabbar

987987987

29-MAR-50

Av. G. 7

M

2500

987654321

4

James

E

Borg

888665555

10-NOV-27

Av. H. 8

M

5500

null

1

Sistemas de Banco de Dados

Sistemas de Banco de Dados: conceitos e arquiteturas

Unidade II

DEPARTAMENTO

DNOME

DNÚMERO

 

NSSGER

 

DATINICGER

 

Pesquisa

5

333445555

22-MAI-78

 

Administrativo

4

9876543231

01-JAN-85

 

Gerencial

1

888655555

19-JUN-71

 

LOCAIS_DEPTO

DNÚMERO

DLOCALIZAÇÃO

 

1

Housson

4

Stafford

5

Bellaire

5

Sugariand

5

Housson

PROJETO

PNOME

PNÚMERO

PLOCALIZAÇÃO

   

DNUM

 

ProdutoX

1

Bellaire

   

5

ProdutoY

2

Sugarland

   

5

ProdutoZ

3

Houston

   

5

Automação

10

Stafford

   

4

Reorganização

20

Houston

   

1

Beneficiamento

30

Stafford

   

4

TRABALHA EM

NSSEMP

PNRO

 

HORAS

 

123456789

1

32,5

 

123456789

2

7,5

666884444

3

40,0

 

453453453

1

20,0

 

453453453

2

20,0

 

333445555

2

10,0

 

333445555

3

10,0

 

333445555

10

10,0

 

999887777

20

10,0

 

999887777

30

30,0

 

987987987

10

10,0

 

987987987

10

35,0

 

987654321

30

5,0

987654321

30

20,0

 

321654987

20

Null

 

DEPENDENTE

NSSEMP

NOMEDEPENDENTE

SEXO

 

DATANIV

RELAÇÃO

333445555

Alice

F

05-ABR-76

 

FILHA

333445555

Theodore

M

25-OUT-73

 

FILHO

333445555

Joy

F

03-MAI-48

 

ESPOSA

987654321

Abner

M

29-FEV-78

 

MARIDO

123456789

Michael

M

01-JAN-78

 

FILHO

123456789

Alice

F

31-DEZ-78

 

FILHA

1234565789

Elizabeth

F

05-MAI-57

 

ESPOSA

Fonte: Adaptado de Takai, Italiano, Ferreira , 2005.

Pós-Graduação a Distância

Sistemas de Banco de Dados: conceitos e arquiteturas

Unidade II

Figura 4.3. Esquema da base de dados relacional COMPANHIA

EMPREGADO PNOME MNOME SNOME NSS DATANASC ENDEREÇO SEXO SALÁRIO NSSSUPER NDEP DEPARTAMENTO DNOME ONÚMERO
EMPREGADO
PNOME
MNOME
SNOME
NSS
DATANASC
ENDEREÇO
SEXO
SALÁRIO
NSSSUPER
NDEP
DEPARTAMENTO
DNOME
ONÚMERO
NSSGER
DATINICGER
LOCAIS_DEPTO
DNÚMERO
DLOCALIZAÇÃO
PROJETO
PNOME
PNÚMERO
PLOCALIZAÇÃO
DNUM
TRABALHA EM
NSSEMP
PNRO
HORAS
DEPENDENTE
NSSEMP
NOMEDEPENDENTE
SEXO
DATANIV
RELAÇÃO

Fonte: Adaptado de Takai, italiano, Ferreira, 2005.

Figura 4.4. Esquema COMPANHIA com restrições de integridade

EMPREGADO

           
 

MNOME

     

PNOME

   

NSS

DATANASC

ENDEREÇO

 
DEPARTAMENTO

DEPARTAMENTO

SNOME

SNOME NSSGER HORAS

NSSGER

SNOME NSSGER HORAS

HORAS

 

SEXO

DNOME

 

ONÚMERO

 

DATINICGER

 
 

LOCAIS_DEPTO

   
 

DNÚMERO

   

PROJETO

   
 

PNOME

 

PLOCALIZAÇÃO

   
 

TRABALHA EM

   
DNUM

DNUM

 

NSSEMP

 

PNRO