Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Projeto de Banco de Dados

Tipos de Banco de Dados

Banco de dados Relacional

Um banco de dados relacional consiste em uma coleo de tabelas, que podem ser relacionadas atravs de seus atributos, ou seja uma linha de uma tabela pode estar sendo relacionada com uma outra linha em uma outra tabela.

Banco de dados rede

Enquanto no modelo relacional os dados e os relacionamentos entre dados so representados por uma coleo de tabelas, modelo de rede representa os dados por colees de registros e os relacionamentos entre dados so representados por ligaes. Ou seja um banco de dados de rede consiste em uma coleo de registros que so conectados uns aos outros por meio de ligaes. Cada registro uma coleo de campos (atributos), cada um desses campos contendo apenas um valor de dado. Uma ligao uma associao entre precisamente dos registros. Cliente Nome Paulo Rua Oliveira Cidade Campinas Conta Nmero 100-01 Saldo 100,00

Banco de dados Hierrquico

Assim como no modelo de Redes o modelo Hierrquico trabalho com os dados e relacionamentos como uma coleo de registros relacionados por ligaes. A nica diferena entre os dois que o modelo Hierrquico os registros so organizados como colees de rvores em vez de grafos arbitrrios. Cliente Nome Paulo Rua Oliveira Cidade Campinas

Conta Nmero 100-01 Saldo 100,00

Fases do Projeto de Base de Dados

O Projeto de Base de Dados pode ser decomposto em:

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Projeto Conceitual

Esquema Conceitual

Independe do DBMS escolhido Modelo Conceitual: Linguagem usada para descrever esquemas conceituais

Projeto Lgico

Modelo lgico: Linguagem usada para especificar esquemas lgicos Pertencem a trs classes: Relacional, Redes e Hierrquico

Projeto Fsico

Esquema Fsico

Esquema fsico: a descrio da Implementao da base de dados em memria secundria. Descreve estruturas de armazenamento e mtodos de acesso. Tem forte ligao com o DBMS especfico.

Resumindo
Projeto Conceitual: No tem dependncia com a classe do GBD a ser escolhido. Projeto Lgico: Tem dependncia com a classe, mas no com o GBD especfico. Projeto Fsico: Total dependncia do GBD especfico.

Concluses
Uma das vantagens em se trabalhar com projeto conceitual est na possibilidade de se adiar a escolha do GBD (mesmo a sua classe). O projetista deve concentrar o maior esforo nesta fase do projeto pois, a passagem para as outras fases mais ou menos automtica. Outra vantagem est na possibildade de usurios no especialistas em bancos de dados darem diretamente a sua contribuio no projeto conceitual cuja maior exigncia a capaciade de abstrao. A aproximao com o usurio final melhora bastante a qualidade do projeto.

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Projeto Conceitual
O Projeto Conceitual produz um esquema conceitual a partir de requisitos de um mundo real. Projeto conceitual usa modelo de dados para descrever a realidade. Um modelo de dados se ampara em um conjunto de blocos de construo primitivas.

Abstrao
Processo que consiste em mostrar as caractersticas e propriedades essenciais de um conjunto de objetos, ou esconder as caractersticas no essenciais.
Quando pensamos no objeto bicicleta de uma forma abstrata, normalmente esquecemos seus detalhes e as particularidades que as diferem entre si.

Abstraes em Projetos Conceituais

Existem 3 Tipos: Classificao Agregao Generalizao

Classificao
Usada para reunir objetos do mundo real com propiedades comuns, formando (ou definindo) classes.

Classificao e Instanciao

Classificaes Multiplas

Agregao
Usada para definir uma nova classe a partir de um conjunto de classes que representam suas partes componentes.

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Agregao e Decomposio

Generalizao
Usada para definir uma classe mais genrica a partir de duas ou mais classes.

Generalizao e Especializao

Exemplos de Generalizao

Exemplos Adicionais

Cobertura da Generalizao
Total / Exclusiva Total / No Exclusiva

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Modelos de Dados
Conceitos: Modelo e Esquema
Um modelo de dados uma coleo de conceitos usados para para descrever uma dada realidade. Estes conceitos so construidos com base nos mecanismos de abstrao e so descritos atravs de representaes grficas e lingsticas. Um esquema uma representao de uma poro especfica da realidade usando-se um particular modelo de dados.

Para exemplificar vamos utilizar o modelo de entidades e relacionamentos (M.E.R.) o qual veremos com maior detalhamento mais adiante)

Modelo de Entidades e Relacionamentos

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Exemplo de Esquema

Exemplos de Instncia

H dois tipos de modelos de dados: Mod. Concietuais : so ferramentas que representam a realidade num alto nvel de abstrao. Mod. Lgicos : suportam descries de dados que podem ser processadas (por um computador). Incluem os modelos relacional, hierrquico e rede.

Obs: projeto de base de dados no a nica aplicao de modelos conceituais. Eles podem ser excelentes ferramentas para gesto em empresas. Por recomendao do comit ANSI/SPARC (metade dos anos 70) todo sistema de base de dados deveria ser organizado de acordo com 3 nveis de abstrao de dados: Externo: tambm chamado de viso. Descreve o ponto de vista de grupos especficos de usurios sobre a poro da base de dados que interessante preservar para aquele grupo particular. Conceitual : representao de alto nvel, independente da mquina, sobre toda a base de dados. Tambm chamada de Enterprise Scheme . Interno: descrio da implementao fsica da base de dados. Dependente da mquina.

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

M. E. R. - O Modelo de Entidades e Relacionamentos

o mais difundido modelo de dados para projeto conceitual de base de dados. Foi introduzido por Peter Chen (1976) e posteriormente recebeu extenses.

Elementos bsicos do modelo: Entidades e Relacionamentos Entidades

Representam classes de objetos do mundo real. Exemplos: FUNCIONRIOS, ALUNOS, PROFESSORES, CIDADES, etc.

Representao grfica da entidade Funcionrios

Relacionamentos
Representam agregaes de duas ou mais entidades. Exemplos: Nascidos em entre Funcionrios e Cidades e Vivem em tambm entre Funcionrios e Cidades.

Representao grfica da entidade Vivem em

O relacionamento pode conectar mais que duas entidades simultaneamente . Neste caso, chamado relacionamento mltiplo.

Relacionamento mltiplo Reserva

Um relacionamento pode conectar entidades de um mesmo conjunto. Neste caso temos o autorelacionamento.

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Auto-relacionamento Gerenciam

Vamos considerar o esquema dos relacionamentos entre Funcionrios e Cidades. Para este esquema poderamos ter a seguinte instncia: FUNCIONRIOS = { f1, f2, f3, f4 } CIDADES = { c1, c2, c3 } VIVEM_EM = { <f1,c1>, <f2,c1>, <f3,c2>, <f4,c3> } NASCIDOS_EM = { <f1,c1>, <f2,c1>, <f3,c2>, <f4,c2> }

Cardinalidades podem ser expressas atravs de valores mnimos e mximos. Por exemplo: MIN_CARD (FUNCIONRIOS, VIVEM_EM) = 1 MAX_CARD (FUNCIONRIOS, VIVEM_EM) = 1 MIN_CARD (CIDADES, VIVEM_EM) = 0 MAX_CARD (CIDADES, VIVEM_EM) = N

Ns declaramos atravs desta representao (lngistica) que o relacionamento Vivem em vrios para um entre Funcionrios e Cidades, atravs de Vivem em. A participao de Funcionrios obrigatria no relacionamento, enquanto a de Cidades opcional. Outra forma de declarar as cardinalidades acima seria: CARD (FUNCIONRIOS, VIVEM_EM) = (1,1) CARD (CIDADES, VIVEM_EM) = (0,n)

Representao grfica correspondente declarao lingstica acima:

Outra representao para o exemplo acima mostrada atravs do esquema abaixo. Esta ser a representao que normalmente seguiremos.

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Existem casos prticos em que um conjunto de entidades representa elementos do mundo real que se subdividem em categorias. Esta subdiviso pode ser representada pelo particionamento do conjunto de entidades o que representa uma abstrao de generalizao (ou especializao). Exemplo:

Extenses do Modelo: Agregao

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Atributos
Representam propriedades elementares de entidades ou relacionamentos. Exemplos:

Tipos de Atributos

Obs: os atributos determinantes determinam univocamente um objeto dentro de um conjunto de entidades. Exemplos adicionais:

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Exemplo 1

Exemplo 2

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Exemplo 3

Exemplo 4

O relacionamento Colao relaciona pares de alunos. Cada par envolve dois alunos: um com o status de Colador e outro com o status de Colado. O relacionamento Delao envolve um aluno na condio de Delator e um par de alunos envolvidos na cola (Colador e Colado).

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Transformaes e Estratgias de Projeto

Primitivas: top down e bottom up Estratgias: top down, bottom up e mista Metodolgias: guiam o projeto atravs de estratgias primitivas

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Primitivas top down

Primitiva Top Down T1

Primitiva Top Down T2

Primitiva Top Down T3

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Primitiva Top Down T4

Primitiva Top Down T5

Primitiva Top Down T6

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Exemplos de primitivas top down:

Exemplo de T1

Exemplo de T2

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Exemplo de T3

Exemplo de T4

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Exemplo de T5

Exemplo de T6

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Primitivas bottom up

Primitiva Botton Up B1

Primitiva Botton Up B2

Primitiva Botton Up B3

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Primitiva Botton Up B4

Primitiva Botton Up B5

Exemplo de primitivas bottom up:

Exemplo de B2

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Exemplo de B3

Exemplo de B4

Exemplo de B5

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Necessidade de reestruturao

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Estratgia top down

Exemplo de um projeto estritamente top down

A) primeiro refinamento

B) segundo refinamento (T1)

C) terceiro refinamento ( T2 e T6 )

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

D) esquema final ( T1 e T6)

Vantagens do top down : o projetista pode atravs de refinamentos independentes analisar um conceito a cada instante. Desvantagem: nem sempre o projetista tem em mente a viso high-level .

Estratgia bottom up
Exemplo de um projeto estritamente bottom up:

A) primeiro esquema

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

b) segundo esquema (B4)

C) terceiro esquema (B3)

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

d) quarto esquema (B2)

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Comparaes entre as metodologias bottom up e top down

Vantagens do top down
conveniente em organizaes altamente estruturadas onde o gerente tem uma viso completa do domnio da aplicao em alto nvel de abstrao.

Vantagens do bottom up
conveniente em organizaes no muito estruturadas onde fcil discutir detalhes e depois agreg-las.

Dicas
Dica 1: tentar conduzir uma sesso de projeto de forma top down na sua essncia e excepcionalmente usar primitivas bottom up ( para, por exemplo, quando o projetista esqueceu algum conceito no nvel mais alto do refinamento). Dica 2: mesmo que o projetista tenha lanado mo de conceitos bottom up, tentar fazer a documentao como se ele fosse top down.

Estratgia mista
Envolve conceitos top down e bottom up. A estratgia mista baseada no particionamento controlado dos requisitos. O projetista produz um frame ( ou esqueleto) para posterior integrao . O frame contem os conceitos mais importantes da aplicao e os links entre as parties.

Estratgia mista - exemplo

A) esquema esqueleto

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

B) esquema pessoas

C) esquema local

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Integrao de vises
necessria quando a aplicao foi quebrada em partes e necessita de integrao para gerar o esquema final a partir dos diferentes views . Tamb m necesria quando as vises partiram de diferentes projetistas ou a partir de bases de dados diferentes.

Problemas que influenciam a atividade de integrao

A) diferentes perspectivas

B) construes equivalentes

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

c) especificao incorreta

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Procedimentos para integrao das vises

Quando mais que dois esquemas devem ser integrados a dica faz-lo dois a dois como mostra a figura abaixo.

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Mapeamento para o Modelo Relacional

A obteno de um modelo lgico a partir de um modelo conceitual pode ser feita pela aplicao de um conjunto de regras bem definidas. Essas regras basicamente atuaro em dois grupos distintos de elementos: as estruturas de relacionamento, agregao e especializao de um lado e as entidades e seus atributos de outro.

Mapeamento do Modelo Relacional

Conceitual

Esquema

lgico

Relacional

Rede

Hierarq.

Fsico

Oracle, SQLServer, etc...

Essas regras so apresentadas mais abaixo :

Entidades Entidades
As entidades iro gerar sempre uma tabela no Modelo Relacional.

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

CA

CA

Entidades - Tabelas

Atributos Multivalorados
Os atributos Multivalorados criaro uma tabela auxiliar, que receber os atributos determinantes (chave) da tabela principal e o prprio atributo se tornar um atributo determinante nessa nova tabela.

CA

T1

T2*

T2_TAB

CA

T2

Atributos Multivalorados

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Relacionamentos Relao N:N

Nos relacionamentos N:N, cada entidade e o relacionamento viraro tabelas.

CA

CB

CA CAR CAR

CB CBR t CBR

CA

CB

Relacionamento N:N
Relao 1:N ou N:1 com obrigatoriedade
Para esses relacionamentos a entidade fraca, ou seja aquela entidade onde a obrigatoriedade se encontra, ir vencer e receber o atributo determinante (chave).

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

CA

CB

CA CAR

CA

CAR

CB

Relacionamento 1:N com obrigatoriedade

Relao 1:N ou N:1 sem obrigatoriedade
Para esses relacionamento podemos ter duas possibilidades, dependendo do modelamento que est sendo feito. Podemos ter a entidade recebendo o atributo determinante (chave) ou o relacionamento se tornando mais uma tabela.

CA

CB

CA CAR

CA

CAR

CB

CA CAR CAR

CB CBR CBR

CA

CB

Relacionamento 1:N sem obrigatoriedade

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Relao 1:1 com obrigatoriedade

Assim como nos relacionamento 1:N com obrigatoriedade, nesses relacionamentos a entidade fraca, ou seja aquela entidade onde a obrigatoriedade se encontra, ir vencer e receber o atributo determinante (chave).

CA

CB

CA CAR

CA

CAR

CB

Relacionamento 1:1 com obrigatoriedade

Relao 1:1 sem obrigatoriedade
Nesses relacionamentos o prprio mundo que est sendo modelado dever identificar qual das d uas entidades devero receber o atributo determinante (chave).

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

CA

CB

CA CAR

CA

CAR

CB

CB CBR

CA

CBR

CB

Relacionamento 1:1 sem obrigatoriedade

Autorelacionamento N:N
Nesses relacionamentos a entidade e o relacionamento geraro duas tabelas, o relacionamento por sua vez receber dois atributos determinantes da entidade.

CA

CA CAR1 CA CAR2 CAR1

CA

CAR2

Autorelacionamento N:N

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Autore lacionamento 1:N ou N:1 com obrigatoriedade

Nesses relacionamentos 1:N com obrigatoriedade, a entidade fraca, e sendo assim ir receber o atributo determinante (chave).

CA

CA

CAR

Autorelacionamento 1:N ou N:1 com obrigatoriedade

Autorelacionamento 1:N ou N:1 sem obrigatoriedade
Para esses relacionamento podemos ter duas possibilidades, dependendo do modelamento que est sendo feito. Podemos ter a entidade recebendo o atributo determinante (chave) ou o relacionamento se tornando mais uma tabela.

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

CA

CA

CAR

CA
A

CAR1 CA CAR2

CA

CAR1

CBR2

Autorelacionamento 1:N ou N:1 sem obrigatoriedade

Agregao
O relacionamento N:N resolvido da forma j vista anteriormente. A agregao nada mais do que o relacionamento entre relacionamentos, desta forma a relao com a entidade C vai acontecer conforme as regras mostradas anteriormente (considerando que o relacionamento A:B gere uma entidade agregada.

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Agregao

CA

CB

CC

CA CAR CAR CAR CBR

CB CBR CBR CAR CBR

CA

CB

CAR CC

CBR

Relacionamento Triplo
Nesses relacionamentos as regras de atribuio do atributo determinante vai depender do modelamento, alm se seguir todas as regras determinadas anteriormente. O importante notar que todas as entidades esto relacionadas ao mesmo tempo.

Puc-Campinas Banco de Dados I Projeto de Banco de Dados

Relacionamento Triplo

CA

CB

CC

CA CAR CAR

CB CBR CBR

CA

CCR

CB

CC CCR

CC