processo de projeto e implementação de bancos de dados daniel callegari material base gentilmente...

Processo de Projeto e Implementação de Bancos de Dados

Daniel Callegari

Material base gentilmente cedido pela prof. Karin Becker

2

Projeto de Bancos de DadosProjeto de Bancos de Dados

projetistas se apóiam pouco em metodologias sistemáticas para conduzir o processo de projeto da base de dados

conseqüências freqüentemente observadas tempo e recursos são subestimados resultado não atende às necessidades das aplicações documentação é limitada manutenção é uma dor de cabeça

3


falta a compreensão sobre a informação a ser armazenada e manipulada O QUÊ? Domínio do Problema

projeto acaba sendo feito diretamente em termos de estruturas de armazenamento COMO? Domínio da Solução

(“mas qual era mesmo o problema ???)

4


problemas do projeto feito em termos de estruturas de armazenamento : leva em conta as limitações da estrutura escolhida inclui os “macetes” para obtenção de um bom desempenho e

para capacidade de representação da informação convívio com a inadequação da estrutura escolhida

(prematuramente) dificulta diálogo com o usuário com o tempo, esquece-se o que é característica da “realidade”,

e o que é necessidade de implementação

5

Processo de Projeto da Base de DadosProcesso de Projeto da Base de Dados

UdD

Enunciado dos Requisitos

Esquema Conceitual

Esquema Lógico

Esquema Físico

Independente de um SGBD

Eliciação de Requisitos

Modelagem Conceitual

Projeto Físico

Mapeamento (Projeto Lógico)Dependente de um SGBD

6

Processo : Eliciação de RequisitosProcesso : Eliciação de Requisitos Eliciação de Requisitos (Requisitos dos Dados)

Entrada : Universo de Discurso (UdD) “realidade” da organização a informação a ser tratada com todas suas propriedades, requisitos e

restrições “nebulosa”, sem fronteiras definidas, inexata

Processo coleta e análise entrevistas, documentos, formulários, observações

Resultado : Especificação de Requisitos descrição “aproximativa”, em linguagem natural Descrição em formatos mais estruturados (Casos de Uso) possivelmente acompanhada de documentos e formulários

7

Processo : Modelagem ConceitualProcesso : Modelagem Conceitual Modelagem Conceitual

Entrada : Especificação dos Requisitos Dependendo da formalidade da especificação

informal, dúbio, incompleto, redundante, contraditório, incoerente ... longo, de difícil manipulação

Processo Modelagem, de acordo com um modelo conceitual

Entidade Relacionamento, UML

Resultado : Esquema Conceitual descrição sucinta (diagramas e texto) clara, concisa, sem ambigüidades, sem contradições padronizada

8

Esquema Conceitual

Obs: Notação UML da ferramenta Rational Rose

participaçãopersonagemcache Ator

nomeArtisitconacionalidadeidadesexo<<0-n>> tipo_papel

Estudionomedonofundaçãofaturamento

Diretornomenacionalidade<<0-n>> premio

Filme<<pk>> nome<<pk>> data<<unique>> copyrightduraçãocusto

1..*1..* 1..*1..*

1

*

+produz1

+produzido-por*

1

1..*

1

1..*

direção

9

Processo : Projeto LógicoProcesso : Projeto Lógico Projeto Lógico

Entrada : Esquema Conceitual Processo

mapeamento regras mais ou menos padronizadas em função do modelo conceitual

usado e a família do SGBD alvo Exemplo:

esquema ER para esquema relacional é standard mapeamento esquema OO em esquema relacional tem menos consenso

Resultado : Esquema Lógico descrição das estruturas de representação na base de dados depende da família de SGBD alvo (relacional, OO, objeto relacional)

10

Esquema Lógico (Relacional)

Obs: Representação gráfica de projeto relacional da ferramenta Rose (Data Modeller)

(mapeamento semi-automático)

T_Ator- nomeArtisitco : VARCHAR(1)+ nacionalidade : VARCHAR(1)+ idade : SMALLINT+ sexo : CHAR(1)+ tipo_papel : VARCHAR(1)+ name : SMALLINT

<<PK>> + PK_T_Ator9()

T_participação+ personagem : VARCHAR(1)+ cache : FLOAT(2147483647)nome : VARCHAR(1)data : TIMESTAMP WITH TIME ZONEnomeArtisitco : VARCHAR(1)

<<PK>> + PK_T_participação7()<<FK>> + FK_T_participação7()<<FK>> + FK_T_participação6()<<Index>> + TC_T_participação15()

1 0..*1 0..*

<<Identifying>>

T_Estudio- nome : SMALLINT+ dono : SMALLINT+ fundação : SMALLINT+ faturamento : SMALLINT

<<PK>> + PK_T_Estudio6()

T_Diretor- nome : SMALLINT+ nacionalidade : SMALLINT+ premio : SMALLINT

<<PK>> + PK_T_Diretor10()

T_Filme- nome : VARCHAR(1)- data : TIMESTAMP WITH TIME ZONE+ copyright : CHAR(1)+ duração : SMALLINT+ custo : SMALLINT# T_Estudio_nome : SMALLINT# T_Diretor_nome : SMALLINT

<<PK>> + PK_T_Filme8()<<FK>> + FK_T_Filme8()<<FK>> + FK_T_Filme5()<<Index>> + TC_T_Filme13()<<Index>> + TC_T_Filme17()

1

0..*

1

0..*<<Identifying>>

1 0..*1 0..*

<<Non-Identifying>>

11..* 11..*

<<Non-Identifying>>

11

Processo : Projeto FísicoProcesso : Projeto Físico

Projeto Físico Entrada: Esquema Lógico Processo

escolha ou refinamento das estruturas de armazenamento e métodos de acesso

leva em consideração o produto de SGBD específico realimenta o esquema lógico

Resultado descrição do esquema na DDL do SGBD

12

Esquema Físico (Relacional)

create table Ator ( nome_artistico varchar(60) not null, nac char(5) not null, idade numeric(1) not null, sexo char(1) not null, primary key (nome_artistico));

create table Diretor ( ID_Dir char(10) not null, nome char(10) not null, nacionalidade char(10) not null, primary key (ID_Dir));

create table Estudio ( nome varchar(20) not null, dono char(1) not null, fundacao date not null,

• Obs: geração de código automática, feita pela ferramenta DB-Main a partir do projeto lógico

13

Modelagem Conceitual de Bancos de DadoModelagem Conceitual de Bancos de Dado Modelagem Conceitual Modelos Conceituais

Modelo Entidade-Relacionamento Modelo UML (Diagrama de Classes)

Técnicas de Modelagem Mecanismos de Abstração Prática com Ferramentas Case

14

Modelagem ConceitualModelagem Conceitual

descrição do conteúdo da base de dados, e não das estruturas de dados usadas para representá-lo

enfoque: compreensão e descrição da “realidade” (informação) compreensão e seleção das propriedades relevantes da

informação compreensão e descrição das restrições sobre os dados diálogo com o usuário desconsidera todo e qualquer aspecto de implementação

15

Modelagem Conceitual : VantagensModelagem Conceitual : Vantagens Vantagens

facilita a compreensão da informação a ser representada e manipulada foca a compreensão e descrição da informação e suas

propriedades muito do processo de projeto lógio e implementação é

automatizável

16


bom veículo de comunicação entre as várias partes envolvidas preciso, simples, padrão não envolve considerações de implementação conforme e completo em relação a um modelo de referência coerente: sem ambigüidades, sem contradições representação diagramática que ressalta os aspectos mais

importantes

17


independência de uma representação específica (produto de SGBD específico) a escolha do SGBD alvo pode ser postergada o esquema conceitual “sobrevive” a mudanças de SGBD alvo é um ponto de partida mais conveniente para novas atividades de

projeto em caso de alterações de requisitos ou do SGBD alvo facilita integração de esquemas

manutenção comparações interoperabilidade

facilidade de manutenção da documentação ferramentas de engenharia reversa

18

Modelo ConceitualModelo Conceitual

modelo conceitual (semântico) modelos mais voltados à “realidade” a representar

(Universo do Discurso - UdD) ferramental conceitual

conceitos dados relacionamentos restrições de integridade

regras de utilização regras de verificação

19

Qualidades de um Modelo ConceitualQualidades de um Modelo Conceitual expressividade

riqueza de conceitos para expressar o maior número possível de características do UdD, sem anotações complementares

simplicidade fácil de aprender fácil de compreender os esquemas resultantes fácil de associar com o UdD representado normalmente entra em conflito com o requisito

“expressividade”

20

Qualidades de um Modelo ConceitualQualidades de um Modelo Conceitual formalidade

cada conceito do modelo tem uma interpretação única, precisa e bem definida

não deve precisar de anotações complementares para compreensão da descrição gráfica/textual

minimalidade (ortogonalidade) cada característica da realidade deve ter uma única forma de

representação boa representação diagramática

não deve ser necessário recorrer à especificação textual para compreensão do esquema representado pelo diagrama

21

Modelos Semânticos : ExemplosModelos Semânticos : Exemplos

Modelo Entidade-Relacionamento ER Extendido ER Canônico

UML Precursores: OMT, OOAD, BOOCH, etc

Acadêmicos Semantic Association Model Semantic Data Model Functional Data Model Temporal Data Model etc

22

Modelo Entidade-Relacionamento (ER)Modelo Entidade-Relacionamento (ER)

Peter Chen “The entity-relationship model - towards a unified view of data”, ACM

TODS, 1976 voltado à representação dos aspectos estáticos do UdD

(informação) modelagem semântica dos dados

popular simplicidade expressividade

campeão das extensões algumas extensões serão vistas neste curso

23

Modelo UMLModelo UML

OMG Com esforço initial de Jackobson, Booch e Rambaugh

voltado à representação dos aspectos estáticos, dinâmicos e funcionais do UdD Nesta disciplina: diagrama de classes

popular Padronização de mercado complexo

Ainda não é apoiado a contento por ferramentas Um problema a ser enfrentado por esta disciplina

processo de projeto e implementação de bancos de dados daniel callegari material base gentilmente...

Documents