20
Unidade 1. Introdução a Projeto de Banco de Dados 1.1 Primeiras Palavras O projetista de banco de dados é o profissional que conhece as ferramentas de modelagem de base de dados e as aplica para materializar um banco de dados da maneira a satisfazer todos os requisitos do usuário. Ele deve achar a equação que pondera o espaço de armazenamento e a performance e para isso deve ter em mente que é necessário fazer vários níveis de refinamento para melhorar o projeto. Como melhorar o projeto? Como aumentar o desempenho? Como melhorar a confiabilidade? As respostas dessas perguntas serão discutidas neste e nos próximos capítulos. 1.2 Problematizando o tema O que é projeto de banco de dados? Quais suas etapas? Como tomar a melhor decisão em um projeto de banco de dados? 1.3 Conceitos Básicos Bancos de dados tornaram-se essenciais em nosso dia a dia. São inúmeras as aplicações que utilizam sistemas de banco de dados: bancos financeiros: armazenam todas as transações bancárias empresas aéreas: reservas de assentos em vôos, agendamentos de vôos vendas: clientes, produtos, estoques, compras revendedores online: registro de pedidos, recomendações personalizadas industria: produção, estoque, pedidos, fornecedores recursos humanos: registro de empregados, salários, dedução de taxas universidades: registros de alunos, disciplinas, salas, notas bibliotecas: registro de acervo, registro de usuário, registro de empréstimo Muitas dessas aplicações são ditas aplicações tradicionais de banco de dados, pois envolvem essencialmente textos e números, porém têm crescido as aplicações que envolvem dados ditos não convencionais como áudio, vídeo, mapas, imagens de satélites, etc. O emprego de avanços tecnológicos tornaram possíveis aplicações inovadoras de sistemas de banco de dados, tais como: banco de dados multimídia: armazenam e manipulam figuras, videoclipes, mensagens sonoras; sistemas de informações geográficas: armazenam e analisam mapas, dados do tempo e imagens de satélite;

Projeto de Banco de Dados - Capítulo 1

Embed Size (px)

Citation preview

Page 1: Projeto de Banco de Dados - Capítulo 1

Unidade 1. Introdução a Projeto de Banco de Dados

1.1 Primeiras Palavras

O projetista de banco de dados é o profissional que conhece as ferramentas de

modelagem de base de dados e as aplica para materializar um banco de dados da

maneira a satisfazer todos os requisitos do usuário. Ele deve achar a equação que

pondera o espaço de armazenamento e a performance e para isso deve ter em mente

que é necessário fazer vários níveis de refinamento para melhorar o projeto. Como

melhorar o projeto? Como aumentar o desempenho? Como melhorar a confiabilidade?

As respostas dessas perguntas serão discutidas neste e nos próximos capítulos.

1.2 Problematizando o tema

O que é projeto de banco de dados? Quais suas etapas? Como tomar a melhor

decisão em um projeto de banco de dados?

1.3 Conceitos Básicos

Bancos de dados tornaram-se essenciais em nosso dia a dia. São inúmeras as

aplicações que utilizam sistemas de banco de dados:

bancos financeiros: armazenam todas as transações bancárias

empresas aéreas: reservas de assentos em vôos, agendamentos de vôos

vendas: clientes, produtos, estoques, compras

revendedores online: registro de pedidos, recomendações personalizadas

industria: produção, estoque, pedidos, fornecedores

recursos humanos: registro de empregados, salários, dedução de taxas

universidades: registros de alunos, disciplinas, salas, notas

bibliotecas: registro de acervo, registro de usuário, registro de empréstimo

Muitas dessas aplicações são ditas aplicações tradicionais de banco de dados, pois

envolvem essencialmente textos e números, porém têm crescido as aplicações que

envolvem dados ditos não convencionais como áudio, vídeo, mapas, imagens de

satélites, etc.

O emprego de avanços tecnológicos tornaram possíveis aplicações inovadoras de

sistemas de banco de dados, tais como:

banco de dados multimídia: armazenam e manipulam figuras, videoclipes,

mensagens sonoras;

sistemas de informações geográficas: armazenam e analisam mapas, dados do

tempo e imagens de satélite;

Page 2: Projeto de Banco de Dados - Capítulo 1

1

data warehouses: utilizados em conjunto com ferramentas de processamento

analítico online (OLAP) possibilitam empresas extrair e analisar informações

úteis de grandes bancos de dados para tomada de decisão;

tecnologia de bancos de dados ativos e de tempo real são utilizados no

controle de processos industriais e de produção.

tecnologia de banco de dados aplicadas a WWW aprimora a recuperação de

informações pelos usuários da internet.

Para que você possa compreender as aplicações mais avançadas começaremos

explorando bancos de dados convencionais. Nas próximas seções conheceremos um

pouco mais sobre os conceitos que cercam os sistemas de banco de dados.

1.4 O que é Banco de Dados?

Um banco de dados é uma coleção de dados relacionados, que possui algumas

propriedades implícitas [ELMASRI 2005]:

representa aspectos do mundo real (chamado minimundo ou universo do

discurso) e mudanças no minimundo devem ser refletidas no banco de dados;

é uma coleção lógica e coerente de dados com algum significado inerente;

é projetado, construído e povoado por dados que atendem a uma proposta

específica dirigida a um grupo de usuários.

Um banco de dados pode ser gerado e mantido manualmente ou pode ser

computadorizado. Obviamente, aqui abordaremos apenas sobre bancos de dados

computadorizados.

A coleção das informações armazenadas no banco de dados em um determinado

momento é uma instância do banco de dados. O projeto geral do banco de dados é o

esquema do banco de dados. Depois de finalizado, os esquemas raramente são

modificados.

1.5 Banco de Dados versus Processamento de Arquivos

No processamento de arquivos, cada usuário define e implementa os arquivos

necessários para uma aplicação específica, como parte da programação da aplicação.

Mesmo que mais de uma aplicação necessite trabalhar com o mesmo conjunto de

dados, cada aplicação mantém suas informações em arquivos separados e também

as aplicações que os manipulam. Isso implica em redundâncias indesejadas, tanto em

termos de definição e armazenamento de dados quanto de esforço para manter os

dados comuns atualizados.

Utilizando um banco de dados, um único repositório de dados é construído

e mantido para ser acessado por vários usuários.

As principais características da abordagem de banco de dados são:

Page 3: Projeto de Banco de Dados - Capítulo 1

2

natureza autodescritiva do sistema de banco de dados;

isolamento entre os programas e os dados, e a abstração dos dados;

suporte para as múltiplas visões dos dados;

compartilhamento de dados e processamento de transações

1.6 Modelo de Dados

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 oferece uma maneira de descrever o projeto de um banco de dados no nível

físico, lógico e de visão.

É usual encontrarmos a seguinte categorização dos modelos de dados:

Modelo Relacional que representa os dados como uma coleção de tabelas.

Cada tabela possui diversas colunas e cada coluna possui um nome único. É o

modelo de dados mais usado. Esse modelo é um exemplo de um modelo de

dados baseado em registros. Historicamente, o modelo de dados em rede e o

modelo de dados hierárquico precederam o modelo relacional. Esses modelos

estavam intimamente relacionados com sua implementação subjacente.

Modelo Entidade/Relacionamento (MER) é baseado em uma percepção do

mundo real que consiste em uma coleção de objetos básicos, chamados

entidades e as relações entre esses objetos. Uma entidade é uma "coisa" ou

"objeto" no mundo real que é distinguivel dos outros objetos. O MER é muito

usado no projeto de banco de dados conceitual.

Modelo Baseado em Objeto pode ser visto como uma extensão ao modelo ER

com noções de encapsulamento, métodos e identidade de objeto. O modelo

relacional-objeto combina os recursos do modelo orientado a objeto com o

relacional.

Modelo Semi-estruturado permite a especificação dos dados em que itens de

dados individuais do mesmo tipo possam ter distintos conjuntos de atributos.

Isso é o oposto dos modelos mencionados anteriormente. A Extensible Markup

Language (XML) é amplamente utilizada para representar dados semi-

estruturados.

1.7 O que é Sistema de Banco de Dados?

Um sistema de banco de dados contém informação sobre algum extrato do mundo real

do qual se pretende armazenar dados e recuperar informações. Na figura 1.1 está

representada uma configuração simplificada de um sistema de banco de dados.

Page 4: Projeto de Banco de Dados - Capítulo 1

3

Figura 1.1 Configuração simplificada de um sistema de banco de dados (extraida de [ELMASRI 2005] - figura cedida pela Editora Pearson).

Conforme apresentado na Figura 1.1, um sistema de banco de dados é basicamente

constituído por um conjunto de dados interrelacionados, que aparece na figura

como "banco de dados armazenados"; por metadados, ou seja, por um conjunto de

dados sobre os dados e as restrições que se aplicam aos mesmos, que aparece na

figura como " Definição dos Dados Armazenados" - comumente chamado de

Dicionário de Dados; o software gerenciador de banco de dados - que é um ambiente

conveniente e eficiente para acessar os dados, e, finalmente um conjunto de

programas de aplicações e/ou consultas que fazem a interface com o usuário e/ou

programador do sistema.

1.8 Projeto de Banco de Dados

O projeto de um sistema de banco de dados segue as seguintes etapas, apresentadas

no diagrama da Figura 1.2:

Page 5: Projeto de Banco de Dados - Capítulo 1

4

Figura 1.2 Etapas de desenvolvimento de um projeto de sistema de banco de dados. (extraído de [ELMASRI 2005] - ilustração cedida pela editora Pearson)

Levantamento de requisitos (independe do SGBD). Na fase de levantamento de

requisitos e análise de requisitos podem ser aplicadas técnicas de engenharia de

software que facilitam a comunicação entre especialistas de computação e

especialistas de domínio. É uma fase essencial para o desenvolvimento do sistema,

pois a qualidade da solução está intrinsecamente relacionada a um documento de

requisitos preciso.

Projeto Conceitual (independe do SGBD). A etapa de projeto conceitual é realizada

a partir do documento de requisitos e é independente de implementação, ou

seja,independe de SGBD. O fruto desta etapa é a construção de um modelo

conceitual, que será aqui representado por um diagrama entidade relacionamento.

Nesta etapa podem ainda surgir questões sobre os requisitos, sendo recomendável

questionar o especialista do domínio sobre tais dúvidas; neste sentido o modelo

conceitual pode auxiliar no refinamento dos requisitos do sistema.

Page 6: Projeto de Banco de Dados - Capítulo 1

5

Projeto Lógico. Esta etapa tem por objetivo transformar o modelo conceitual em um

modelo lógico. O modelo lógico define como o banco de dados será implementado em

SGBD específico.

Projeto Físico nesta etapa o modelo do banco de dados é enriquecido com detalhes

que influenciam no desempenho do banco de dados, mas não interferem em sua

funcionalidade. O modelo obtido nesta fase é o modelo físico do banco de dados.

Estas etapas, conforme [HEUSER 2008] salienta, são adequadas para a construção

de um novo banco de dados. Caso já exista um banco de dados ou um conjunto de

arquivos convencionais, e se pretenda construir um novo banco de dados, o processo

anterior é modificado e incorpora uma etapa de engenharia reversa.

1.6 Pessoas em torno de um Sistema de Banco de Dados

Nesta seção vamos enfocar os profissionais que no cotidiano se envolvem na

construção, manutenção e uso de um grande banco de dados.

Uma primeira figura que se destaca em ambientes que lidam com grandes

quantidades de dados e que necessitam de adequada gestão desses dados por

intermédio de sistemas de banco de dados é o projetista de banco de dados. Os

projetistas devem entrevistar todos os grupos de possíveis usuários para conhecer

suas necessidades de dados, ou seja, são os responsáveis pela identificação dos

dados que serão armazenados no banco e também por escolher as estruturas

adequadas para representar e armazenar esses dados. Os projetistas começam a

trabalhar antes mesmo do sistema ter sido implementado e alimentado com os dados.

Uma outra figura, não menos importante, em se tratando de grandes bancos de dados

é o administrador de banco de dados (DBA) que é responsável pela autorização para

o acesso ao banco, pela coordenação e monitoração de seu uso e por adquirir

recursos de software e hardware conforme necessário. É responsável por problemas

como brechas de segurança ou tempo de resposta ruim do sistema. Ou seja, o DBA é

o responsável pelo sistema de banco de dados durante toda sua vida útil.

Já foi dito que um sistema de banco de dados é desenvolvido para um grupo de

usuários, então obviamente, este é um grupo de pessoas importante no contexto.

Usuários podem ser categorizados em usuários leigos - são aqueles que interagem

com o sistema apenas por intermédio de programas de aplicação previamente

concebidos; programadores de aplicação - são profissionais de computação que

interagem com o sistema com o intuito de escrever programas de aplicação; usuários

avançados interagem com o sistema sem escrever programas, formulam suas

requisições em uma linguagem de consulta de banco de dados e usuários

especializados são usuários avançados que escrevem aplicações de banco de dados

especializadas que não se encaixam na estrutura de processamento de dados

tradicional.

Page 7: Projeto de Banco de Dados - Capítulo 1

6

1.9 Arquitetura de três-esquemas

A arquitetura de três-esquemas (também conhecida como arquitetura ANSI/SPARC)

para sistemas de banco de dados foi proposta para auxiliar a realização e visualização

de importantes características do uso de banco de dados: independência entre dados

e programas; suporte a múltiplas visões de usuários e uso de catálogo (ou dicionário

de dados) para armazenar a descrição do banco de dados.

O objetivo dessa arquitetura, ilustrada na Figura 1.3, é a separação entre o usuário da

aplicação e o banco de dados físico. Pode-se observar três níveis: o nível interno (ou

físico) que tem um esquema interno que descreve a estrutura de armazenamento

físico do banco de dados. Esse esquema utiliza um modelo de dados físico e descreve

os detalhes completos do armazenamento de dados e caminhos de acesso aos

mesmos. O nível conceitual (ou lógico) que possui um esquema conceitual que

descreve a estrutura de todo o banco de dados para a comunidade usuária. Esse

esquema oculta detalhes de armazenamento físico, concentrando-se em descrição de

entidades, tipos de dados, conexões, operações de usuários e restrições. O nível

externo (ou de visão) abrange os esquemas externos ou visões dos usuários. Cada

esquema externo descreve a parte do banco de dados que um dado grupo de usuários

tem interesse e oculta o restante do banco de dados desse grupo.

Figura 1.3 - Arquitetura Three-Schema (extraída de [ELMASRI 2005])

1.10 Independência de Dados

Page 8: Projeto de Banco de Dados - Capítulo 1

7

Independência de dados é a capacidade de mudar o esquema em um nível do

sistema de banco de dados sem que ocorram alterações do esquema no próximo nível

mais alto. Existem dois tipos de independência de dados: lógica e física.

Independência de dados lógica: é a capacidade de alterar o esquema conceitual

sem mudar o esquema externo ou os programas de aplicação.

Possíveis alterações no esquema externo: adicionar um tipo de registro ou item de

dados, variar restrições ou remover um tipo de registro ou item de dados.

Independência de dados física: é a capacidade de mudar o esquema interno sem

alterar o esquema conceitual. Consequentemente, o esquema externo também não

necessita alteração.

Possíveis mudanças em nível físico podem ser necessariás quando arquivos físicos

precisam ser reorganizados para aperfeiçoar o desempenho da recuperação ou

atualização de dados.

Com um sistema gerenciador de banco de dados (SGBD) que implementa a

arquitetura de três-esquemas, o catálogo é expandido para incluir informações de

como mapear os dados entre níveis. Ou seja, o SGBD utiliza software adicional para

realizar os mapeamentos e garantir a independência de dados o que acarreta uma

sobrecarga durante a compilação ou a execução de uma consulta ou de um programa,

provocando ineficiências no SGBD. Porisso poucos SGBDs implementam a arquitetura

três-esquemas completa.

1.11 Linguagens de Banco de Dados

Após termos obtido o esquema lógico e físico do banco de dados devemos escolher o

Sistema Gerenciador de Banco de Dados (SGBD) que se deseja utilizar para

implementá-lo.

A linguagem de definição de dados (data definition language) é usada pelo DBA e

pelos projetistas do banco de dados para definir ambos os esquemas conceitual e

interno. O SGBD terá um compilador DDL cuja função é processar os comandos DDL

a fim de identificar os construtores e para armazenar a descrição do esquema no

catálogo do SGBD.

Quando os esquemas do banco de dados estiverem compilados e o banco de dados

populado com os dados, os usuários devem ter alguns meios para manipular esse

banco. As manipulações típicas são a recuperação, inserção, remoção e modificação

dos dados. A linguagem de manipulação de dados (DML) é fornecida pelo SGBD para

essa finalidade.

Basicamente, existem dois tipos de DMLs: procedurais e declarativas. As procedurais

requerem que um usuário especifique que dados são necessários e como obtê-los. As

Page 9: Projeto de Banco de Dados - Capítulo 1

8

declarativas exigem apenas que os usuários especifiquem o que desejam sem

especificar como obtê-los.

A parte de uma DML que envolve recuperação de informações é chamada de

linguagem de consulta.

1.12 Software Gerenciador de Banco de Dados

Um Sistema Gerenciador de Banco de Dados (SGBD) é um complexo sistema de

software. Os principais módulos componentes de um SGBD encontram-se ilustrados,

de forma simplificada, na Figura 1.4.

O banco de dados e o catálogo são normalmente armazenados no disco. O acesso ao

disco é controlado principalmente pelo sistema operacional do ambiente onde está

instalado o SGBD. Um módulo de alto nível do SGBD, chamado de módulo de

gerenciamento dos dados armazenados, controla o acesso à informação do SGBD

que está armazenada em disco.

O compilador DDL processa as definições do esquema, especificadas na DDL, e

armazena as descrições dos esquemas no catálogo do SGBD. O catálogo inclui

informações como nomes e tamanhos dos arquivos, nomes e tipos de itens de dados,

detalhes de armazenamento de cada arquivo, informações de mapeamento entre os

esquemas e restrições, além de muitas outras informações necessárias para os

módulos do SGBD. Os módulos de software do SGBD acessam as informações do

catálogo conforme necessário.

O compilador de consulta manipula as consultas de alto nível que são feitas

interativamente. Analisa sintaxe, compila ou interpreta a consulta criando um código

de acesso ao BD e então gera as chamadas ao runtime.

O pré-compilador extrai os comandos DML dos programas escritos em uma linguagem

de programação hospedeira. Esses comandos são enviados ao compilador DML para

compilação, gerando códigos para o acesso ao BD. O restante do programa é enviado

para o compilador da linguagem de programação hospedeira. Os códigos-objeto para

os comandos DML e o restante do programa são acoplados, formando uma transação

customizada cujo código executável inclui as chamadas para o runtime.

O processador de consulta de banco de dados em tempo de execução (runtime)

recebe os comandos para a recuperação ou atualização e os executa no banco de

dados.

Page 10: Projeto de Banco de Dados - Capítulo 1

9

Figura 1.4 - Arquitetura simplicada dos componentes de SGBD. (extraída de [ELMASRI 2006])

Abstrações no Projeto Conceitual de Banco de Dados

Para auxiliar o projetista na tarefa de modelar os dados, existem os mecanismos de

abstração de dados que permitem melhor representar a semântica da informação

envolvida na aplicação. As abstrações comumente usadas no projeto conceitual são:

classificação, agregação e generalização.

Abstração de Classificação: é usada para agrupar objetos similares, caracterizados

por propriedades comuns, em classes de objetos. Ex: classe EMPREGADO -

instancias : (João, Pedro, ..., Maria). A classificação estabelece um relacionamento É-

INSTANCIA-DE entre cada elemento da classe e a classe.

Abstração de Agregação: é um conceito de abstração para construir objetos

compostos a partir de seus objetos componentes. Ex: Uma entidade é uma agregação

de atributos: PESSOA, composta por Nome, Sexo, Profissão. Um relacionamento é

uma agregação de entidades e atributos. Um atributo composto é uma agregação de

atributos. Podem-se agregar entidades relacionadas entre si, compondo uma entidade

de nível mais alto. Essa abstração estabelece um relacionamento É-PARTE-DE entre

os componentes e a classe.

Page 11: Projeto de Banco de Dados - Capítulo 1

10

Abstração de Generalização: define um relacionamento de subconjunto entre os

elementos de duas ou mais classes. Ex: classes CARRO e BICICLETA são

subconjuntos da classe VEÍCULO. Essa abstração estabelece um relacionamento É-

UM entre a classe pai (chamada superclasse) e cada classe filha (subclasse). As

subclasses são definidas com base em alguma característica da superclasse. No

exemplo dado, essa característica é tipo de veículo (Carro, Bicicleta). Propriedade

Fundamental da Generalização: todas as abstrações definidas para a classe

genérica são herdadas por todas as classes que são subconjunto.

Abstração de Divisão: nessa abstração subdivide-se os atributos em partes, criando

um atributo composto;

1.13 Modelo ER (Entity-Relationship)

Devido à popularidade e ampla utilização do modelo Entidade-Relacionamento (ER)

para o projeto conceitual de bancos de dados, várias extensões desse modelo foram

propostas, visando sua utilização para a modelagem de informações mais complexas.

O modelo ER foi proposto por Peter Chen em 1976, sendo que originalmente o modelo

incluia somente os conceitos de entidade, relacionamento e atributos; posteriormente

outros conceitos foram introduzidos no modelo, tais como atributos compostos e

hierarquias de generalização. As entidades representam classes de objetos do mundo

real. Na Figura 1.5, Aluno e Professor são exemplos de entidades. São representadas

graficamente através de um retângulo.

Relacionamentos representam associações entre duas ou mais entidades. Na

Figura 1.5, orienta representa um relacionamento binário entre as entidades Professor e

Aluno, representando que um aluno tem 1 (um) professor como orientador e um

professor orienta n (vários) alunos. Os relacionamentos são representados

graficamente através de losangos.

Os atributos representam propriedades das entidades ou dos relacionamentos.

Na Figura 1.5 tem-se para a entidade Aluno os atributos nro_aluno e nome; Professor

possui os atributos nome, sexo e nro_orientados. O atributo nro_oritentados é atributo

derivado, o valor de um atributo derivado é determinado em função dos valores de

outros atributos ou em função do relacionamento.

Page 12: Projeto de Banco de Dados - Capítulo 1

11

Figura 1.5 Exemplo de Diagrama Entidade-Relacionamento

Cardinalidade mínima e máxima de uma entidade em um relacionamento

Para indicar, de forma mais precisa, a cardinalidade de um relacionamento, pode-se

usar uma notação que indique a ocorrência mínima e máxima de cada entidade no

relacionamento. Por exemplo, a cardinalidade do relacionamento da Figura 1.6 indica

que um aluno pode ou não ter um orientador e pode ter no máximo 1 orientador; um

professor orienta vários alunos, podendo haver professor que não orienta nenhum

aluno.

Figura 1.6 Exemplo de notação de Cardinalidade Mínima e Máxima de um Relacionamento

Cardinalidade mínima e máxima de um atributo

Os atributos também são caracterizados por cardinalidade mínima e máxima. Por

exemplo, na entidade Professor, da Figura 1.7, o atributo títulos possui cardinalidade

mínima 1 e máxima n, indicando que cada professor deve ter no mínimo um título e

pode ter vários. Quando não especificado no atributo, o valor da cardinalidade é (1,1).

A notação comumente adotada na literatura para um atributo multivalorado é um

circulo duplo. A notação de cardinalidade mínima e máxima foi adotada somente

neste material.

Figura 1.7 Cardinalidade mínima e máxima de um atributo.

Page 13: Projeto de Banco de Dados - Capítulo 1

12

Cardinalidade mínima de atributo igual a 0 (zero) indica atributo opcional;

cardinalidade máxima de atributo maior que 1 (um) indica que o atributo é

multivalorado.

Atributos compostos

Um atributo composto representa um grupo de atributos que possuem uma afinidade

em significado ou uso. Como exemplo, considere o atributo endereço na

Figura 1.8, que é composto por Rua, Cidade, Estado e Nro.

Figura 1.8 Exemplo de Atributo Composto

Atributos derivados

Um atributo derivado é um atributo cujo valor pode ser gerado a partir de outros

valores armazenados no banco de dados. Na Figura 1.7, o atributo nro-orientandos é

um atributo derivado, pois pode ser calculado através do relacionamento orienta.

Observe que um atributo derivado é representado através de uma elipse tracejada.

Um identificador interno é um atributo ou grupo de atributos que determina uma

entidade. Será adotada a representação da Figura 1.9 para identificador interno.

Figura 1.9 Identificador interno RA.

Quando uma entidade B é identificada através de outra entidade A associada a ela,

tem-se um identificador externo. A entidade B é chamada entidade fraca. A Figura

1.10 apresenta a notação para a identificação externa. Essa notação indica que o

identificador de A faz parte do identificador de B (Id-B é um identificador parcial de B e

isso está indicado através de um grifo tracejado).

Enderço

rua

nro

CidadeEstado

Page 14: Projeto de Banco de Dados - Capítulo 1

13

Figura 1.10 Exemplo de Identificador Externo

1.14 Extensão do Modelo ER

Para permitir melhor expressar as informações a serem modeladas, foram introduzidos

no modelo ER as hierarquias de generalização e de subconjunto.

Hierarquia de Generalização: Uma classe E é uma generalização de um grupo de

classes E1, E2, ..., En. Se cada objeto das classes E1, E2, ..., En é também um

objeto da classe E. Uma forma de representar uma hierarquia de generalização é

dada na Figura 1.11.

Propriedades de Cobertura da generalização

Cobertura TOTAL ou PARCIAL:

E

E1 E2 En . . .

Figura 1.11 Hierarquia de generalização

Page 15: Projeto de Banco de Dados - Capítulo 1

14

A cobertura de uma generalização é total (t) se cada elemento da classe genérica é

mapeada para pelo menos um elemento das classes especializadas.

Ex: A generalização formada pela classe PESSOA e as subclasses HOMEM e

MULHER (Figura 1.12) possui cobertura total.

A cobertura é parcial (p) se existe algum elemento da classe genérica que não

é mapeado para nenhum elemento das subclasses.

Exemplo: Suponha que VEÍCULO é uma classe que contém outros tipos de veículos

além de carros e bicicletas. A generalização da Figura 1.12 é parcial.

Figura 1.12- cobertura total Figura 1.13- cobertura parcial

Cobertura EXCLUSIVA (DISJUNÇÃO) ou de SOBREPOSIÇÃO (OVERLAPPING): A cobertura de uma generalização é exclusiva (e) se cada elemento da classe

genérica é mapeado para no máximo um elemento das subclasses. Por exemplo, a

Figura 1.14 representa uma cobertura exclusiva.

(p,e)

Figura 1.14. Cobertura parcial e exclusiva.

A cobertura é de sobreposição (s) se existe algum elemento da classe genérica que

é mapeado para elementos de duas ou mais subclasses diferentes. Por exemplo, na

Figura 1.15, supondo que pode existir aluno que cursa a graduação e a pós-graduação

ao mesmo tempo, tem-se uma cobertura de sobreposição.

parcial total

Pessoa

Homem Mulher

Veículo

Carro Bicicleta

Veículo

Carro Bicicleta

Page 16: Projeto de Banco de Dados - Capítulo 1

15

Figura 1.15 Cobertura de sobreposição.

Notação: Para denotar o tipo de cobertura de uma hierarquia de generalização será

usada a seguinte notação: (t,e), (t,s), (p,e), (p,s) e será indicado como na figura 1.12.

Quando em uma generalização a cobertura não está especificada, admite-se que é

(t,e).

Hierarquia de Subconjunto: uma entidade E1 é um subconjunto de uma

entidade E se toda ocorrência de E1 for também uma ocorrência de E (Figura

1.17). É um caso particular da hierarquia de generalização.

Numa hierarquia de subconjunto o tipo de cobertura é (p,e) sempre.

A representação de hierarquia de subconjunto é dada na Figura 1.16

Observações:

1. O identificador da entidade genérica é também um identificador para as entidades

da especialização.

2. Entidades da especialização podem ter outros identificadores, como mostrado na

figura Figura 1.18.

sobreposição

Aluno

Aluno- Graduaçao

Aluno-Pós- Graduação

Cliente

Cliente Especial

nro-cli nome-cli endereço

vantagens

Figura 1.16. Exemplo

E

E1

e1 e2 e3

e4 e5

Figura 1.17. Hierarquia de subconjunto.

Page 17: Projeto de Banco de Dados - Capítulo 1

16

1.15 Considerações finais

Aqui apresentamos os conceitos básicos e definições usadas em projeto de banco de

dados. Neste capítulo, vimos os principais conceitos envolvidos no projeto conceitual

de um banco de dados. Vamos aprofundar esse conhecimento no próximo capítulo

que é dedicado especificamente para projeto e refinamento do projeto conceitual de

um banco de dados.

1.16 Exercícios

1. O que é banco de dados?

2. O que é um SGBD?

3. Qual é a diferença de um Modelo de Dados e um Esquema de Dados?

4. O que é o Modelo Conceitual de Dados?

5. O que é o Modelo Lógico de Dados?

6. O que é o Modelo Físico de Dados?

7. A definição do tipo de índice a ser usado em uma tabela faz parte de qual etapa de

um projeto de banco de dados?

8. A definição do tipo de um atributo (inteiro, alfanumérico,…) faz parte de qual etapa

de um projeto de banco de dados?

9. Nas figuras a seguir, classifique a cobertura das especializações (total/parcial e

exclusiva/sobreposição).

RG Nome título

Situação- Serv-militar

nome-solteira nro-emp nome divisão categoria posição

Pessoa

Homem Mulher Empr Chefe Gerente Militar divisão ident-na-divisão

Figura 1.18. Exemplo de hierarquia.

Page 18: Projeto de Banco de Dados - Capítulo 1

17

10. Interprete as hierarquias de generalização/especialização como um tipo de

relacionamento. Como as restrições de cobertura (total/parcial e

exclusiva/sobreposição) se relacionam com as restrições de relacionamento total,

entidade fraca e cardinalidade mínima e máxima?

11. Transforme as hierarquias da questão 9 em relacionamentos.

12. Simplifique o esquema conceitual a seguir:

(c)

Page 19: Projeto de Banco de Dados - Capítulo 1

18

13. Faça o esquema conceitual para os seguintes requisitos.

- Uma oficina mecânica mantém informações sobre todos seus clientes, fornecedores

e funcionários.

- De cada pessoa armazena-se seu nome, RG, CPF, endereço, telefone (no mínimo

1), e-mail.

- De cada funcionário, armazena-se a data de contratação, seu salário total e seu

salário-hora;

- De cada fornecedor armazena-se seu cnpj

- Para cada serviço realizado, armazena-se os funcionários que o executaram, a data

em que o mesmo foi realizado, o tempo demorado e o valor final cobrado (calculado

com base no preço das peças, custo da mão de obra, acrescida em 30%);

- Um serviço pode envolver produtos/peças comprados de fornecedores. Assim para

cada serviço, os produtos usados e os fornecedores onde os mesmos foram obtidos

devem ser cadastrados; Os fornecedores variam os preços dos produtos. Assim para

cada peça do serviço realizado, deve ser armazenado o preço da mesma ao ser

comprada;

- Mantêm-se todos os tipos de serviços realizados na oficina.

1.17 Estudos complementares

Ler Capítulos 1 e 2 do Livro: Heuser, C.A. Projeto De Banco De Dados Editora

Bookman, Porto Alegre, 6a. Edição, 2009.

1.18 Bibliografia Adicional

Batini, C.; Ceri, S. & Navathe, S.B. - Conceptual Database Design. The Benjamin/Cummings Publishing Company, Inc., 470p., 1992. Elmasri, R.E. & Navathe, S.B.– Fundamentos de Banco de Dados. Addison-Wesley, 4a. Edição, 2005. Silberchatz, A.; Korth, H.F.; Sudarshan, S. - Sistemas de Banco de Dados. Makron Books, 3a.Edição, 1999. Date, C.J. - Introdução a Sistemas de Banco de Dados. Editora Campus, (tradução da 8a. edição), 2004.

Page 20: Projeto de Banco de Dados - Capítulo 1

19

Heuser, C.A. – Projeto de Banco de Dados. Editora Sagra-Luzzato, 5a. Edição, 2001.