Projeto de Banco de Dados

Prévia do material em texto

Sistemas de Gerenciamento Sistemas de Gerenciamento 
de Banco de Dadosde Banco de Dados
Ramakrishnan • Gehrke
Tradução daTradução da
Terceira EdiçãoTerceira Edição
Sistemas de Gerenciamento de Banco de Dados
ISBN 978-85-7726-027-0
A reprodução total ou parcial deste volume por quaisquer formas ou meios, sem o consentimento escrito da editora,
é ilegal e confi gura apropriação indevida dos direitos intelectuais e patrimoniais dos autores.
Copyright © 2008 de McGraw-Hill Interamericana do Brasil Ltda.
Todos os direitos reservados.
Av. Brigadeiro Faria Lima, 201 – 17º. andar
São Paulo, SP, CEP 05426-100
Todos os direitos reservados. Copyrigth © 2008 de McGraw-Hill Interamericana Editores, S. A. de C. V. 
Prol. Paseo de la Reforma 1015 Torre A Piso 17, Col. Desarrollo Santa Fé, Delegación Alvaro Obregón
México 01376, D. F., México
Tradução da terceira edição do original em inglês Database Management Systems.
© 2003, 2000, 1998 de The McGraw-Hill Companies, Inc. 
ISBN da obra original: 0-07-246563-8
Diretor-Geral: Adilson Pereira
Editora: Gisélia Costa
Supervisora de Produção: Guacira Simonelli
Preparação de Texto: Lucrécia Freitas e Mônica de Aguiar
Design da Capa: Mick Wiggins
Editoração Eletrônica: Crontec Ltda.
________________________________________________________________
R165s Ramarkrishnan, Raghu.
Sistemas de gerenciamento de banco de dados
[recurso eletrônico] / Raghu Ramarkrishnan,Johannes 
Gehrke ; tradução: Célia Taniwake. – 3. ed. – Dados
eletrônicos. – Porto Alegre : AMGH, 2011. 
 
Editado também como livro impresso em 2008.
ISBN 978-85-63308-77-1
1. Ciência da computação. 2. Bases de dados – 
Gerenciamento. I. Gehrke, Johannes. II. Título. 
CDU 004.658 
________________________________________________________________
Catalogação na publicação: Ana Paula Magnus – CRB 10/2052
21
2
INTRODUÇÃO AO PROJETO
DE BANCO DE DADOS
Quais são as etapas do projeto de um banco de dados?
Por que o modelo ER é utilizado para criar um projeto inicial?
Quais são os principais conceitos do modelo ER?
Quais são as diretrizes para se utilizar efetivamente o modelo ER?
Como o projeto de banco de dados se encaixa dentro da estrutura de projeto geral 
de um software complexo dentro de grandes empresas?
O que é UML e como ela está relacionada com o modelo ER?
Conceitos-chave: projeto de banco de dados, projeto conceitual, lógico e físico; 
modelo ER (entidade-relacionamento), conjunto de entidades, conjunto de rela-
cionamentos, atributo, instância, chave; restrições de integridade, relacionamen-
tos um-para-muitos e muitos-para-muitos; restrições de participação; entidades 
fracas, hierarquias de classe, agregração; UML, diagramas de classe, diagramas de 
banco de dados, diagramas de componente.
☛
☛
☛
☛
☛
☛
➽
Os homens mais bem-sucedidos do mundo usam a imaginação. Eles consideram 
o futuro, concebem seus modelos mentais, e depois trabalham para materializar esse 
modelo em todos os seus detalhes, completando aqui, acrescentando um pouco ali, 
alterando esse ou aquele pedacinho, mas constantemente criando, constantemente 
criando.
— Robert Collier
O modelo de dados entidade-relacionamento (ER) nos permite descrever os dados en-
volvidos em uma empresa do mundo real em termos de objetos e seus relacionamentos 
e é amplamente utilizado para desenvolver um projeto inicial de banco de dados. Ele 
fornece conceitos úteis que nos possibilitam mover de uma descrição informal do que 
os usuários desejavam de seu banco de dados para uma descrição mais detalhada e 
22 CAPÍTULO 2
precisa que pode ser implementada em um SGBD. Neste capítulo, introduziremos o 
modelo ER e discutiremos como seus recursos nos permitem modelar fielmente uma 
ampla variedade de dados.
Iniciaremos com uma visão geral do projeto de banco de dados na Seção 2.1 para 
motivar nossa discussão sobre o modelo ER. Dentro de um contexto maior do processo 
de projeto geral, o modelo ER é utilizado em uma fase chamada projeto conceitual 
de banco de dados. Introduziremos, então, o modelo ER nas seções 2.2, 2.3 e 2.4. Na 
Seção 2.5, discutiremos os aspectos de projeto de banco de dados envolvendo o modelo 
ER. Discorreremos brevemente sobre o projeto conceitual de banco de dados para grandes 
empresas na Seção 2.6. Na Seção 2.7, apresentaremos uma visão geral da UML, uma abor-
dagem de projeto e modelagem que é mais geral em seu escopo do que o modelo ER.
Na Seção 2.8, introduziremos um estudo de caso utilizado como um exemplo real 
em todo o livro. O estudo de caso é um projeto completo de banco de dados, para 
uma loja na Internet. Ilustraremos as duas primeiras etapas do projeto de banco de 
dados (análise de requisitos e projeto conceitual) na Seção 2.8. Nos capítulos poste-
riores, estenderemos o estudo de caso para abranger as etapas restantes do processo 
de projeto.
Observamos que muitas variantes dos diagramas ER estão em uso, sem que nenhum 
padrão amplamente aceito prevaleça. A apresentação deste capítulo é representativa 
da família dos modelos ER e inclui uma seleção dos recursos mais populares.
2.1 PROJETO DE BANCO DE DADOS E DIAGRAMAS ER
Iniciamos nossa discussão sobre projeto de banco de dados observando que esta é, 
tipicamente, apenas uma parte, embora seja uma parte central nos aplicativos que 
fazem uso intensivo de dados, de um projeto maior de sistema de software. Nosso foco 
primário é o projeto do banco de dados, e não discutiremos outros aspectos do projeto 
de software. Retomaremos esse ponto na Seção 2.7.
O processo de projeto de banco de dados pode ser dividido em seis etapas. O mo-
delo ER é o mais relevante nas três primeiras etapas.
1. Análise de Requisitos: A primeira etapa no projeto de um aplicativo de banco de 
dados é compreender quais dados devem ser armazenados, que aplicativos devem 
ser criados para manipular esses dados, e quais operações são mais freqüentes e 
sujeitas a requisitos de desempenho. Em outras palavras, devemos descobrir o que 
os usuários desejam do banco de dados. Normalmente, esse é um processo informal 
que envolve discussões com grupos de usuários, um estudo do ambiente operacio-
nal em vigor e como é esperado que ele se altere, análise de toda a documentação 
disponível sobre os aplicativos existentes que se deseja substituir ou complementar 
com o banco de dados e assim por diante. Várias metodologias têm sido propostas 
para organizar e apresentar as informações coletadas nesta etapa, e algumas fer-
ramentas automatizadas têm sido desenvolvidas para apoiar o processo.
2. Projeto Conceitual do Banco de Dados: As informações coletadas na etapa de 
análise de requisitos são usadas para desenvolver uma descrição de alto nível dos 
dados a serem armazenados, juntamente com as restrições conhecidas para serem apli-
cadas sobre estes dados. Esta etapa normalmente é conduzida utilizando o modelo ER 
e é discutida no restante deste capítulo. O modelo ER é um dos diversos modelos 
de dados semânticos, ou de alto nível, utilizados no projeto de banco de dados. O 
objetivo é criar uma descrição simples dos dados que melhor corresponda à visão 
ou idéia que os usuários e desenvolvedores têm em relação aos dados (e às pessoas 
e processos a serem representados nos dados). Isso facilita a discussão entre todas 
Introdução ao Projeto de Banco de Dados 23
as pessoas envolvidas no processo de projeto, inclusive aquelas que não possuem 
conhecimento técnico. Ao mesmo tempo, o projeto inicial deve ser suficientemente 
preciso para permitir uma conversão direta em um modelo de dados suportado 
por um sistema de banco de dados comercial (o que, na prática, significa o modelo 
relacional).
3. Projeto Lógico de Banco de Dados: Devemos escolher um SGBD para implementar 
nosso projeto de banco de dados, e converter o projeto conceitual em um esquema 
de banco de dados no modelo de dados do SGBD escolhido. Consideraremos apenas 
os SGBDs relacionais e, assim, a tarefa na etapa de projeto lógico consiste em con-
verter um esquema ER em umesquema de banco de dados relacional. Discutimos 
esta etapa em detalhes no Capítulo 3; o resultado é um esquema conceitual, tam-
bém chamado de esquema lógico, no modelo de dados relacional.
2.1.1 Além do Projeto ER
O diagrama ER é apenas uma descrição aproximada dos dados, criada através de uma 
avaliação subjetiva das informações coletadas durante a análise de requisitos. Uma 
análise mais cuidadosa normalmente pode refinar o esquema lógico obtido no final 
da Etapa 3 anterior. Uma vez que tenhamos um esquema lógico, devemos considerar 
o critério de desempenho e projetar o esquema físico. Finalmente, devemos tratar os 
aspectos de segurança e assegurar que os usuários sejam capazes de acessar os dados 
de que eles precisam, mas não os dados que desejamos ocultar deles. As três etapas 
restantes do projeto de banco de dados são descritas brevemente em seguida:
4. Refinamento do Esquema: A quarta etapa no projeto de banco de dados consiste em 
analisar a coleção de relações em nosso esquema de banco de dados relacional para 
identificar problemas em potencial e refiná-los. Em contraste às etapas de análise 
de requisitos e projeto conceitual, que são essencialmente subjetivas, o refinamento 
do esquema pode ser conduzido por uma teoria elegante e poderosa. Discutiremos 
a teoria de normalização de relações — reestruturação das relações para assegurar 
algumas propriedades desejáveis — no Capítulo 19.
5. Projeto Físico de Banco de Dados: Nesta etapa, consideramos as cargas típicas es-
peradas que nosso banco de dados deve suportar e refinamos ainda mais o projeto 
de banco de dados para assegurar que ele satisfaça os critérios de desempenho de-
sejados. Esta etapa pode apenas envolver a criação de índices em algumas tabelas 
e agrupamento de tabelas, ou pode envolver um reprojeto substancial de partes do 
esquema de banco de dados obtido das etapas anteriores de projeto. Discutiremos 
o projeto físico e a sintonização (tuning) de banco de dados no Capítulo 20.
6. Projeto de Aplicativos e Segurança: Qualquer projeto de software que envolva um 
SGBD deve considerar aspectos do aplicativo que vão além do banco de dados pro-
Ferramentas para Projeto de Banco de Dados: As ferramentas de projeto são 
disponibilizadas por fabricantes de SGBD Relacionais, assim como por fabri-
cantes de produtos de terceiros. Por exemplo, veja o seguinte link para detalhes 
sobre ferramentas de projeto e análise da Sybase:
http://www.sybase.com/products/applicationhttp://www.sybase.com/products/application_tools.tools.
O link seguinte fornece detalhes das ferramentas da Oracle:
http://www.oracle.com/tools.http://www.oracle.com/tools.
24 CAPÍTULO 2
priamente dito. Metodologias de projeto, como a UML (Seção 2.7), tentam tratar 
o projeto de software e o ciclo de desenvolvimento completo. Brevemente, devemos 
identificar as entidades (por exemplo, usuários, grupos de usuários, departamen-
tos) e os processos envolvidos no aplicativo. Devemos descrever o papel de cada 
entidade em cada processo que é refletido em alguma tarefa de aplicativo, como 
parte de um fluxo dessa tarefa. Para cada papel, devemos identificar as partes do 
banco de dados que devem ser acessíveis e as partes que não devem ser acessíveis, 
e devemos tomar medidas para assegurar que essas regras de acesso sejam obede-
cidas. Um SGBD fornece diversos mecanismos para auxiliar esta etapa, que serão 
discutidos no Capítulo 21.
Na fase de implementação, devemos codificar cada tarefa em uma linguagem de 
aplicativo (Java, por exemplo), utilizando o SGBD para acessar os dados. Discutire-
mos o desenvolvimento de aplicativos nos capítulos 6 e 7.
Em geral, nossa divisão do processo de projeto em etapas deve ser vista como uma 
classificação dos tipos de etapas envolvidas no projeto. Realisticamente, embora possa-
mos começar com um processo de seis etapas esboçadas aqui, um projeto completo de 
banco de dados provavelmente exigirá uma fase de sintonização (tuning) subseqüente, 
na qual todos os seis tipos de etapas de projeto são intercalados e repetidos até que o 
projeto esteja satisfatório.
2.2 ENTIDADES, ATRIBUTOS E CONJUNTOS DE ENTIDADES
Uma entidade é um objeto do mundo real distinguível de outros objetos. Exemplos 
incluem: o brinquedo Dragonzord Verde, o departamento de brinquedos, o gerente do 
departamento de brinquedos, o endereço residencial do gerente do departamento de 
brinquedos. Normalmente, é útil identificar uma coleção de entidades semelhantes. 
Tal coleção é chamada conjunto de entidades. Observe que os conjuntos de entidades 
não precisam ser disjuntos: o conjunto de funcionários do departamento de brinquedos 
e o conjunto de funcionários do departamento de utensílios podem ambos conter o 
funcionário John Doe (que pode trabalhar em ambos os departamentos). Poderíamos 
também definir um conjunto de entidades chamado Funcionários que contém os con-
juntos de funcionários dos dois departamentos: de brinquedos e de utensílios.
Uma entidade é descrita utilizando-se um conjunto de atributos. Todas as enti-
dades em um determinado conjunto de entidades têm os mesmos atributos; isto é o 
que queremos dizer com semelhantes. (Essa afirmação é uma simplificação exagerada, 
como veremos quando discutirmos as hierarquias de herança na Seção 2.4.4, mas ela 
satisfaz por ora, e realça a idéia principal.) Nossa escolha de atributos reflete o nível 
de detalhes com os quais desejamos representar as informações sobre as entidades. Por 
exemplo, o conjunto de entidades Funcionários poderia usar nome, código de pessoa 
física (CPF) e vaga de estacionamento como atributos. Nesse caso, armazenaremos o 
nome, CPF e número da vaga do estacionamento para cada funcionário. Entretanto, 
não armazenaremos, digamos, o endereço de um funcionário (ou o sexo ou a idade).
Para cada atributo associado a um conjunto de entidades, devemos identificar um 
domínio de possíveis valores. Por exemplo, o domínio do atributo nome de Funcio-
nários poderia ser o conjunto de cadeias de 20 caracteres.1 Como outro exemplo, se a 
1 Para evitar confusão, consideramos que os nomes de atributos não se repetem ao longo dos conjuntos de 
entidades. Isso não é uma limitação real, uma vez que sempre podemos usar o nome do conjunto de entidades 
para resolver as ambigüidades quando o mesmo nome de atributo for utilizado em mais de um conjunto de 
entidades.
Introdução ao Projeto de Banco de Dados 25
empresa avalia funcionários em uma escala de 1 a 10 e armazena as avaliações em um 
campo chamado avaliação, o domínio associado consiste em inteiros de 1 a 10. Além 
disso, para cada conjunto de entidades, escolhemos uma chave, que consiste em um 
conjunto mínimo de atributos cujos valores identificam unicamente uma entidade do 
conjunto. Pode haver mais de uma chave candidata; se houver, designamos uma delas 
como a chave primária. Por enquanto, consideramos que cada conjunto de entidades 
contém no mínimo um conjunto de atributos que identifica unicamente uma entidade 
no conjunto inteiro; ou seja, o conjunto de atributos contém uma chave. Retomaremos 
esse ponto na Seção 2.4.3.
O conjunto de entidades Funcionários com atributos cpf, nome e vaga é ilustrado na 
Figura 2.1. Um conjunto de entidades é representado por um retângulo, e um atributo 
é representado por um símbolo oval. Cada atributo da chave primária é sublinhado. A 
informação do domínio poderia ser listada juntamente com o nome do atributo, mas 
omitimos isso para manter as figuras compactas. A chave é cpf.
nome
vaga
Funcionários
cpf
Figura 2.1 O conjunto de entidades Funcionários.
2.3 RELACIONAMENTOS E CONJUNTOS DE 
RELACIONAMENTOS
Um relacionamento é uma associação entre duas ou mais entidades. Por exemplo, 
podemos ter o relacionamento em que Attishoo trabalha no departamento de farmá-
cia. Como com as entidades, podemos desejar reunir um conjunto de relacionamentos 
semelhantes em um conjunto de relacionamentos. Um conjunto de relacionamentos pode 
ser considerado um conjunto de n-tuplas:
{(e1, ...,en) | e1 ΠE1, ... , en ΠEn}
Cada n-tupla denota um relacionamento envolvendo n entidades e1 a en, sendo 
que a entidade ei pertence ao conjunto de entidades Ei. Na Figura 2.2 ilustramos o 
conjunto de relacionamentos Trabalha_em, no qual cada relacionamento indica um 
departamento em que um funcionário trabalha. Observe que diversos conjuntos de 
relacionamentos podem envolver os mesmos conjuntos de entidades. Por exemplo, 
poderíamos também ter um relacionamento Gerencia envolvendo Funcionários e De-
partamentos.
Um relacionamento também pode ter atributos descritivos. Estes são usados para 
registrar informações sobre o relacionamento em vez de sobre uma das entidades 
participantes; por exemplo, podemos desejar registrar que Attishoo trabalha no de-
partamento de farmácia a partir de janeiro de 1991. Essa informação é registrada na 
Figura 2.2, adicionando-se um atributo, desde, a Trabalha_em. Um relacionamento 
deve ser identificado unicamente pelas entidades participantes, sem referência aos atri-
26 CAPÍTULO 2
butos descritivos. No conjunto de relacionamento Trabalha_em, por exemplo, cada 
relacionamento Trabalha_em deve ser identificado univocamente pela combinação de 
cpf de funcionário e id-depto de departamento. Assim, para um determinado par fun-
cionário-departamento, não podemos ter mais de um valor desde associado.
cpf id-depto orçamento
Trabalha_emFuncionários
nome
vaga
desde
Departamentos
nome-depto
Figura 2.2 O conjunto de relacionamentos Trabalha_em.
Uma instância de um conjunto de relacionamentos é um conjunto de seus relacio-
namentos. Intuitivamente, uma instância pode ser considerada o ‘retrato’ do conjunto 
de relacionamentos em determinado momento. Uma instância do conjunto de rela-
cionamentos Trabalha_em é ilustrada na Figura 2.3. Cada entidade Funcionários é 
denotada pelo seu cpf, e cada entidade Departamentos é denotada pela sua id-depto, 
por simplicidade. O valor desde é ilustrado ao lado de cada relacionamento. (Os co-
mentários ‘muitos-para-muitos’ e ‘participação total’ na figura serão discutidos poste-
riormente, quando discutirmos restrições de integridade.)
Figura 2.3 Uma instância do conjunto de relacionamentos Trabalha_em.
Como outro exemplo de um diagrama ER, suponha que cada departamento tenha 
escritórios em diversas localidades e desejamos registrar as localidades nas quais cada 
funcionário trabalha. Esse relacionamento é ternário porque devemos registrar uma 
associação entre um funcionário, um departamento e uma localidade. O diagrama ER 
para essa variante de Trabalha_em, que denominamos Trabalha_em2, é ilustrado na 
Figura 2.4.
Encerra aqui o trecho do livro disponibilizado para 
esta Unidade de Aprendizagem. Na Biblioteca Virtual 
da Instituição, você encontra a obra na íntegra.