Fase 2 - Projeto Conceitual do Banco de Dados

Prévia do material em texto

4 - Fase 2: projeto conceitual do banco de dados 
 
A segunda fase do projeto de banco de dados envolve duas atividades 
paralelas. A primeira atividade, o projeto do esquema conceitual, examina os 
requisitos de dados resultantes da Fase 1 e produz, um esquema conceitual do 
banco de dados. A segunda atividade, o projeto de transação e aplicação, 
examina as aplicações de banco de dados analisadas na Fase 1 e produz 
especificações de alto nível para essas aplicações. 
 
Fase 2a: Projeto do esquema conceitual. 
 
 O esquema conceitual produzido por essa fase normalmente é contido em um 
modelo de dados de alto nível independente do SGBD pelas seguintes razões: 
 1 - O objetivo do projeto do esquema conceitual é um conhecimento 
completo da estrutura do banco de dados, do significado (semântica), dos inter-
relacionamentos e das restrições. Isso é mais bem alcançado 
independentemente de um SGBD específico, porque cada SGBD com 
freqüência possui particularidades e restrições que não deverão influenciar o 
projeto do esquema conceitual. 
 2 - O esquema conceitual é valioso como uma descrição estável do 
conteúdo de banco de dados. A escolha do SGBD e, mais tarde, as decisões 
de projeto podem mudar sem alterar o esquema conceitual independente do 
SGBD. 
 3 - Um bom conhecimento do esquema conceitual é crucial para os 
usuários de banco de dados e projetistas de aplicação. O uso de um modelo de 
dados de alto nível que é mais expressivo e geral do que os modelos de dados 
dos SGBDs individuais é, portanto, muito importante. 
 4 - A descrição diagramática do esquema conceitual pode servir como 
um veículo de comunicação entre os usuários do banco de dados, projetistas e 
analistas. Como os modelos de dados de alto nível normalmente contam com 
os conceitos que são mais fáceis de entender do que os modelos de dados 
específicos do SGBD em nível mais baixo, ou definições sintáticas dos dados, 
qualquer comunicação referente ao projeto de esquema torna-se mais exata e 
mais direta. 
Nessa fase do projeto de banco de dados, é importante usar um modelo de 
dados contetual de alto nível com as seguintes características: 
 1 - Expressividade. O modelo de dados deve ser expressivo o suficiente 
para distinguir diferentes tipos de dados, relacionamentos e restrições; 
 2 - Simplicidade e compreensão. O modelo deve ser simples o suficiente 
para que usuários típicos não especialistas compreendam e usem seus 
conceitos; 
 3 - Minimalista. O modelo deve ter um número pequeno de conceitos 
básicos, que são distintos e não sobrepostos no significado; 
 4 - Representação diagramática. O modelo deverá ter uma notação 
diagramática para exibir um esquema conceitual que seja fácil de interpretar; 
 5 - Formalidade. Um esquema conceitual expresso no modelo de dados 
deve representar uma especificação não ambígua formal dos dados. Logo, os 
conceitos do modelo devem ser definidos com precisão e sem ambigüidade. 
Alguns desses requisitos, o primeiro, em particular, às vezes entram em conflito 
com outros requisitos. Na discussão a seguir, usaremos a terminologia do 
modelo Entidade-Rel acionamento Estendido (EER) e assumiremos que ele 
está sendo usado nesta fase. O projeto do esquema conceitual, incluindo a 
modelagem de dados, está se tornando uma parte integral das metodologias 
de análise e projeto orientadas a objeto. A UML possui diagramas de classes 
que, em grande parte, são baseados em extensões do modelo EER. 
 
Técnicas para o projeto de esquema conceitual. 
 
Para o projeto de esquema conceitual, devemos identificar os componentes 
básicos (ou construções) do esquema: os tipos de entidade, tipos de 
relacionamento e atributos. Também devemos especificar atributos-chave, 
cardinalidade e restrições de participação nos relacionamentos, tipos de 
entidade fraca e hierarquias/reticuladas de especialização/generalização. 
Existem duas técnicas para designar o esquema conceitual, que é derivado dos 
requisitos coletados durante a Fase 1. 
A primeira técnica é a técnica de projeto de esquema centralizado (ou única 
tentativa), em que os requisitos das diferentes aplicações e grupos de usuários 
da Fase 1 são mesclados em um único conjunto de requisitos antes que o 
projeto do esquema comece. Um único esquema correspondente ao conjunto 
mesclado de requisitos é então projetado. Quando existem muitos usuários e 
aplicações, mesclar todos os requisitos pode ser uma tarefa árdua e demorada. 
Supõe-se que uma autoridade centralizada, o DBA, seja responsável por 
decidir como mesclar os requisitos e projetar o esquema conceitual para o 
banco de dados inteiro. Uma vez que o esquema conceitual esteja projetado e 
finalizado, os esquemas externos para diversos grupos de usuários e 
aplicações podem ser especificados pelo DBA. 
A segunda técnica é a técnica de integração de visão, em que os requisitos não 
são mesclados. Em vez disso, um esquema (ou visão) é projetado para cada 
grupo de usuários ou aplicação com base apenas nos próprios requisitos. 
Assim, desenvolvemos um esquema de alto nível (visão) para cada grupo de 
usuários ou aplicação desse tipo. Durante a fase de integração de visão 
subseqüente, esses esquemas são mesclados ou integrados em um esquema 
conceitual global para o banco de dados inteiro. As visões individuais podem 
ser reconstruídas como esquemas externos após a integração da visão. 
A principal diferença entre as duas técnicas está na maneira e no estágio em 
que várias visões ou requisitos dos muitos usuários e aplicações são 
reconciliados e mesclados. Na técnica centralizada, a reconciliação é feita 
manualmente pelo DBA antes do projeto de quaisquer esquemas, e aplicada 
diretamente aos requisitos coletados na Fase 1, Isso coloca o peso para 
reconciliar as diferenças e conflitos entre os grupos de usuários no DBA. O 
problema costuma ser tratado usando consultores/especialistas em projeto 
externos, que aplicam seus métodos específicos para resolver esses conflitos. 
Devido às dificuldades de gerenciar essa tarefa, a técnica de integração de 
visão tem sido proposta como uma alternativa. 
Na técnica de integração de visão, cada grupo de usuários ou aplicação 
realmente projeta o próprio esquema conceitual (EER) com base em seus 
requisitos, com assistência do DBA. Depois, um processo de integração é 
aplicado a esses esquemas (visões) pelo DBA para formar um esquema 
integrado global. Embora a integração de visão possa ser feita manualmente, 
sua aplicação em um grande banco de dados, envolvendo dezenas de grupos 
de usuários, requer uma metodologia e o uso de ferramentas automatizadas. 
As correspondências entre os atributos, tipos de entidade e tipos de 
relacionamento nas diversas visões precisam ser especificadas antes que a 
integração possa ser aplicada. Adicionalmente, problemas como a integração 
de visões em conflito e a verificação da consistência das correspondências 
especificadas entre esquemas precisam ser tratados. 
 
Estratégias para projeto de esquema. 
 
Dado um conjunto de requisitos, seja para um único usuário ou para uma 
grande comunidade de usuários, temos de criar um esquema conceitual que 
satisfaça tais requisitos. Existem diversas estratégias para projetar tal 
esquema. A maioria das estratégias segue uma técnica incremental — ou seja, 
elas começam com algumas construções de esquema importantes derivadas 
dos requisitos e depois modificam, detalham e constroem incrementalmente 
sobre elas. Agora, vamos discutir algumas dessas estratégias: 
1. Estratégia de cima para baixo (top-down). Começamos com um 
esquema contendo abstrações de alto nível e depois aplicamos 
sucessivos detalhamentos de cima para baixo.Por exemplo, podemos 
especificar apenas alguns tipos de entidade de alto nível e depois, à 
medida que especificarmos seus atributos, dividi-los em tipos de 
entidade de nível inferior e especificar os relacionamentos. 
2. Estratégia de baixo para cima (bottom-up). Comece com um 
esquema contendo abstrações básicas e depois combine ou acrescente 
algo a essas abstrações. Por exemplo, podemos começar com os 
atributos de banco de dados e agrupá-los em tipos de entidade e 
relacionamentos. Podemos acrescentar novos relacionamentos entre os 
tipos de entidade à medida que o projeto prossegue. O processo de 
generalizar tipos de entidades em superclasses generalizadas de nível 
mais alto é outra atividade durante a estratégia de projeto de baixo para 
cima. 
3. Estratégia de dentro para fora (inside-out) Esse é um caso especial 
de uma estratégia de cima para baixo, em que a atenção é focada em 
um conjunto central de conceitos que são mais evidentes. A modelagem 
então se espalha para fora, considerando novos conceitos nas 
vizinhanças dos existentes. Poderíamos especificar alguns tipos de 
entidade claramente evidentes no esquema e continuar acrescentando 
outros tipos de entidade e relacionamentos que estão ligados a cada 
um. 
4. Estratégia mista. Em vez de seguir qualquer estratégia particular por 
todo o projeto, os requisitos são particionados de acordo com uma 
estratégia de cima para baixo, e parte do esquema é projetado para 
cada partição de acordo com uma estratégia de baixo para cima. As 
diversas partes do esquema são então combinadas. 
 
As figuras 10.2 e 10.3 ilustram alguns exemplos simples de detalhamento de 
cima para baixo e de baixo para cima, respectivamente. Um exemplo de 
detalhamento de cima para baixo primitivo é a decomposição de um tipo de 
entidade em vários tipos de entidade. A Figura 10.2(a) mostra uma 
DISCIPLINA sendo detalhada para DISCIPLINA e SEMINÁRIO, e o 
relacionamento ENSINA é dividido, da mesma forma, em ENSINA e 
OFERECE. A Figura 10.2(b) mostra um tipo de entidade 
OFERTA_DISCIPLINA sendo detalhado para dois tipos de entidade 
(DISCIPLINA e PROFESSOR) e um relacionamento entre eles. O 
detalhamento normalmente força um projetista a fazer mais perguntas e extrair 
mais restrições e detalhes: por exemplo, as razões de cardinalidade (min, max) 
entre DISCIPLINA e PROFESSOR são obtidas durante o detalhamento. A 
Figura 10.3(a) mostra o primitivo de detalhamento de baixo pra cima da 
geração de relacionamentos entre os tipos de entidade DOCENTE e ALUNO. 
Dois relacionamentos são identificados: ACONSELHA e 
TUTOR_RESPONSAVEL. O detalhamento de baixo para cima que usa a 
categorização (tipo de união) é ilustrado na Figura 10.3(b), onde o novo 
conceito de PROPRIETARIO_VEICULO é descoberto com base nos tipos de 
entidade existentes DOCENTE, ADMINISTRATIVO e ALUNO. 
 
 
 
integração de esquema (visão) 
 
 Para grandes bancos de dados, com muitos usuários e aplicações esperadas, 
pode ser utilizada a técnica de integração de visão do projeto de esquemas 
individuais para depois mesclá-los. Como as visões individuais podem ser 
mantidas relativamente pequenas, o projeto dos esquemas é simplificado. 
Porém, uma metodologia para integrar as visões em um esquema de banco de 
dados global é necessário. A integração de esquema pode ser dividida nas 
seguintes subtarefas: 
1. Identificar correspondências e conflitos entre os esquemas. Como os 
esquemas são projetados individualmente, é necessário especificar 
construções nos esquemas que representam o mesmo conceito do 
mundo real. Essas correspondências devem ser identificadas antes que 
a integração possa prosseguir. Durante esse processo, vários tipos de 
conflitos entre os esquemas podem ser descobertos: 
a) Conflitos de nomes. Estes são de dois tipos; sinônimos e homônimos. 
Um sinônimo ocorre quando dois esquemas utilizam diferentes nomes 
para descrever o mesmo conceito. Por exemplo, um tipo de entidade 
CONSUMIDOR em um esquema pode descrever o mesmo conceito de 
um tipo de entidade CLIENTE em outro esquema. Um homônimo ocorre 
quando dois esquemas usam o mesmo nome para descrever diferente 
conceitos. Por exemplo, um tipo de entidade PECA pode representar 
peças de computador em um esquema e peças de mobília em outro 
esquema. 
b) Conflitos de tipo. O mesmo conceito pode ser representado em dois 
esquemas por diferentes construções de modelagem. Por exemplo, o 
conceito de um DEPARTAMENTO pode ser um tipo de entidade em um 
esquema e um atributo em outro esquema. 
c) Conflitos de domínio (conjunto de valores). Um atributo pode ter 
diferentes domínios em dois esquemas. Por exemplo, Cpf pode ser 
declarado como um inteiro em um esquema e como uma cadeia de 
caracteres em outro. Um conflito da unidade de medida poderia ocorrer 
se um esquenta representasse Peso em libras e o outro usasse 
quilogramas. 
d) Conflitos entre restrições. Dois esquemas podem impor diferentes 
restrições; por exemplo, uma chave de um tipo de entidade pode ser 
diferente em cada esquema. Outro exemplo envolve diferentes 
restrições estruturais em um relacionamento como ENSINA. Um 
esquema pode representá-lo como 1:N (uma disciplina tem um 
professor), enquanto outro esquema o representa como M:N (uma 
disciplina pode ter mais de um professor). 
2. Modificar visões para que se tornem semelhantes. Alguns esquemas 
são modificados de modo que sejam ajustados a outros esquemas mais 
parecidos. Alguns dos conflitos identificados na primeira subtarefa são 
resolvidos durante essa etapa. 
3. Mesclar visões. O esquema global é criado pela mescla dos esquemas 
individuais. Conceitos correspondentes são representados apenas uma 
vez no esquema global, e os mapeamentos entre as visões e o esquema 
global são especificados. Essa é a etapa mais difícil de alcançar nos 
bancos de dados da vida real envolvendo dezenas ou centenas de 
entidades e relacionamentos. Ela envolve uma quantidade considerável 
de intervenção humana e negociação para resolver conflitos e decidir 
sobre as soluções mais razoáveis e aceitáveis para um esquema global. 
4. Reestruturar. Como uma última etapa opcional, o esquema global pode 
ser analisado e reestruturado para remover quaisquer redundâncias ou 
complexidade desnecessária. 
 
 
Algumas dessas idéias são ilustradas pelo exemplo relativamente simples 
apresentado nas Figuras 10.4 e 10.5. Na Figura 10.4, duas visões são 
mescladas para criar um banco de dados bibliográfico. Durante a identificação 
das correspondências entre as duas visões, descobrimos que PESQUISADOR 
e AUTOR são sinônimos (em se tratando desse banco de dados), assim como 
CONTRIBUIDO_POR e ESCRITO_POR. Além disso, decidimos modificar a 
VISÃO 1 a fim de incluir um ASSUNTO para ARTIGO, como mostra a Figura 
10.4, para adequar-se à VISÃO 2. 
 
A Figura 10.5 mostra o resultado da mescla de VISÃO MODIFICADA 1 com a 
VISÃO 2. Generalizamos os tipos de entidade ARTIGO e LIVRO no tipo de 
entidade PUBLICACAO, com seu atributo comum Titulo. Os relacionamentos 
CONTRIBUIDO_POR e ESCRITO_POR são mesclados, assim como os tipos 
de entidade PESQUISADOR e AUTOR. O atributo Editora só se aplica ao tipo 
de entidade LIVRO, enquanto o atributo Tamanho e o tipo de relacionamento 
PUBLICADO_EM só se aplicam a ARTIGO. 
Esse exemplo simples ilustra a complexidade do processo de mescla e como o 
significado dos diversos conceitos precisa ser considerado na simplificação do 
projeto de esquema resultante. Para projetos da vida real, o processo de 
integração de esquema requer uma técnica mais disciplinada e sistemática. 
Várias estratégias foram propostas para o processo de integraçãode visão (ver 
Figura 10.6): 
 
 
 1. Integração em escala binária. Dois esquemas muito semelhantes são 
integrados primeiro, O esquema resultante é então integrado a outro esquema; 
e o processo é repetido até que todos os esquemas sejam integrados. A 
ordenação dos esquemas para integração pode ser baseada em alguma 
medida de semelhança do esquema. Essa estratégia é adequada para a 
integração manual, devido a sua técnica passo a passo. 
 2 - Integração n-ária. Todas as visões são integradas em um 
procedimento após uma análise e especificação de suas correspondências. 
Essa estratégia requer ferramentas computadorizadas para grandes problemas 
de projeto. Tais ferramentas foram montadas como protótipos de pesquisa, 
mas ainda não estão disponíveis para comercialização. 
 3 - Estratégia balanceada binária. Pares de esquemas são integrados 
primeiro, e depois os esquemas resultantes são emparelhados para maior 
integração; esse procedimento é repetido até que o resultado seja um esquema 
global final. 
 4 - Estratégia mista. Inicialmente, os esquemas são particionados em 
grupos com base em sua semelhança, e cada grupo é integrado de maneira 
separada. Os esquemas intermediários são agrupados de novo e integrados, e 
assim por diante. 
 
Fase 2b: projeto de transação. 
 
 A finalidade da Fase 2b, que prossegue em paralelo com a Fase 2a, é projetar 
as características das transações (aplicações) de banco de dados conhecidas 
de uma maneira independente do SGBD. Quando um sistema de banco de 
dados está sendo projetado, os projetistas estão cientes de muitas aplicações 
(ou transações) conhecidas, as quais serão executadas no banco de dados 
uma vez implementado. Uma parte importante do projeto do banco de dados é 
especificar as características funcionais dessas transações desde cedo no 
processo de projeto. Isso garante que o esquema de banco de dados incluirá 
todas as informações exibidas por essas transações. Além disso, conhecer a 
importância relativa das diversas transações e as freqüências esperadas de 
suas chamadas desempenha um papel fundamental durante o projeto físico do 
banco de dados (Fase 5). Normalmente, nem todas as transações do banco de 
dados são conhecidas durante o projeto. 
Depois que o sistema de banco de dados estiver implementado, novas 
transações são continuamente identificadas e implementadas. Porém, as 
transações mais importantes costumam ser conhecidas antes da 
implementação do sistema, e devem ser especificadas em um estágio inicial. A 
regra informal dos 80-20 em geral se aplica nesse contexto: 80 por cento da 
carga de trabalho é representada por 20 por cento das transações usadas com 
mais freqüência, que controlam o projeto físico do banco de dados. Em 
aplicações que são de consultas ocasionais ou da variedade de processamento 
de lote, consultas e aplicações que processam uma quantidade substancial de 
dados devem ser identificadas. 
Uma técnica comum para especificar transações em um nível conceitual é 
identificar sua entrada/saída e o comportamento funcional. Ao determinar os 
parâmetros de entrada e saída (argumentos) e o fluxo de controle funcional 
interno, os projetistas podem especificar uma transação de uma maneira 
conceitual e independente do sistema. As transações normalmente podem ser 
agrupadas em três categorias; (1) transações de recuperação, que são usadas 
para recuperar dados para exibição em uma tela ou imprimir um relatório; (2) 
transações de atualização, que são utilizadas para a inserção de novos dados 
ou modificação de dados existentes no banco de dados; e (3) transações 
mistas, que são usadas para aplicações mais complexas, que realizam alguma 
recuperação e alguma atualização. Por exemplo, considere um banco de dados 
de reservas aéreas. Uma transação de recuperação poderia, primeiro, listar 
todos os vôos matutinos em determinada data entre duas cidades. Uma 
transação de atualização poderia ser uma reserva de um assento em 
determinado vôo. Uma transação mista poderia, em primeiro lugar, exibir 
alguns dados, como mostrar uma reserva do cliente em algum vôo, e depois 
atualizar o banco de dados, como ao cancelar a reserva excluindo-a, ou 
acrescentando um trecho de vôo a uma reserva existente. As transações 
(aplicações) podem ser originadas em uma ferramenta de front-end, como o 
PowerBuilder (da Sybase), que coleta parâmetros on-line e depois envia uma 
transação ao SGBD, como back-end. 
Várias técnicas para especificação de requisitos incluem uma notação para 
especificar processos, os quais nesse contexto são operações mais 
complexas, que podem consistir em várias transações. Ferramentas de 
modelagem de processo, como BPwin, bem como ferramentas de modelagem 
de fluxo de trabalho estão se tornando populares para identificar fluxos de 
informação nas organizações. A linguagem UML, que prove a modelagem de 
dados por meio de diagramas de classes e objetos, possui uma série de 
diagramas de modelagem de processo, incluindo diagramas de transição de 
estado, de atividades, de seqüência e de colaboração. Todos estes se referem 
a atividades, eventos e operações dentro do sistema de informação, as 
entradas e saídas dos processos, os requisitos de seqüência ou sincronismo, e 
outras condições. É possível detalhar essas especificações e extrair transações 
individuais delas. Outras propostas para especificar transações incluem TAXIS, 
GALILEO e GORDAS (veja na bibliografia selecionada deste capítulo). 
Algumas destas foram implementadas em sistemas e ferramentas de protótipo. 
A modelagem de processos contínua sendo uma área de pesquisa ativa. 
O projeto da transação é tão importante quanto o projeto do esquema, mas 
com freqüência é considerado parte da engenharia de software, em vez do 
projeto de banco de dados, Muitas metodologias de projeto atuais enfatizara 
um sobre o outro. Deve-se passar pelas fases 2a e 2b em paralelo, usando 
ciclos de retorno para o detalhamento, até que seja alcançado um projeto 
estável do esquema e das transações.