Mostrando postagens com marcador Fundamentos de PBD. Mostrar todas as postagens
Mostrando postagens com marcador Fundamentos de PBD. Mostrar todas as postagens

quarta-feira, setembro 17, 2008

Normalização - Processo



O Processo de Normalização incorpora na sua essência o mecanismo de decomposição, em que tabelas "mais complexas" contendo dados redundantes são decompostas em tabelas "mais simples" onde essas redundâncias são eliminadas.
Durante o processo de demposição surgem novas tabelas que deverão estar relacionadas com a "tabela origem" por meio de chaves estrangeiras e suas respectivas chaves primárias.






Inconsistência

Inconsistências em BD são decorrentes, principalmente, de dados redundantes que deveriam ser atualizados simultaneamente.

Caso isso não aconteca por alguma razão o banco de dados apresentará informações dúbias, como no exemplo acima.

Redundância


Redundâncias em BD podem ser conseqüências de erros no Projeto Conceitual / Lógico de um BD ou podem ser intencionais durante o Projeto Físico do BD, visando a melhoria de performance no acesso ao BD. Nesse caso a redudância deverá ser controlada para a garantia da consistência do BD.

segunda-feira, setembro 08, 2008

Projeto (Modelagem) de Banco de Dados - PBD - MBD

1) Introdução

A atividade de Projeto de Banco de Dados (PBD) ou Modelagem de Banco de Dados (MBD) é estudada a mais de três décadas e vem sendo, ao longo desse tempo, definida por diversos autores.

A seguir são estabelecidas algumas definições de PBD:

  1. É o processo de desenvolvimento da Estrutura de um Banco de Dados. [TEO82]
  2. É o processo de determinar a organização de um Banco de Dados, incluindo a sua Estrutura, Conteúdo e Aplicações. [CER92]
  3. É o processo de projeto da Estrutura Lógica e Física de um ou mais Bancos de Dados para acomodar as Informações necessárias aos Usuários de uma Organização para um definido conjunto de Aplicações. [ELM89]

2) Definição de Projeto de Banco de Dados:

  1. É a atividade que tem como propósito especificar a Estrutura e o Comportamento de um Banco de Dados (Modelo do Banco de Dados), tendo como ponto de partida os Requisitos de Informação e as Regras de Negócio (Modelo descritivo) inerentes a um determinado Domínio do Problema (Mini-Mundo, Domínio de Conhecimento, Parcela do Mundo Real), com a utilização de Ferramentas de Projeto ou Modelagem (MER, MC-UML, MDR, ...), procurando atender a uma série de critérios de qualidade (Requisitos de Qualidade de Projeto ou Modelagem).


 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
3) Como um Banco de Dados é Projetado ?
Um Banco de Dados é projetado como uma solução para um problema de necessidade de informação persistente e consistente.
Ele é projetado a partir de uma situação no mundo real (Mini-Mundo, Domínio do Problema, Domínio do Conhecimento). Em função da complexidade desse Mini-Mundo, essa atividade normalmente é dividida em fases que geram modelos sucessivos (um a partir de outro) até o modelo final (solução) (Domínio da Solução).
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
4) Fases de Projeto (Modelagem) de Banco de Dados
 
image
 
image 
image

sábado, agosto 23, 2008

Regra de Negócio

Os sistemas de informação abrangem, com freqüência, um grande volume de conhecimento organizacional formalizado.

Tal conhecimento é especificado como regras de negócio, definidas por Bell como sendo “declarações que apresentam a maneira de como o negócio está sendo feito, além das diretrizes e restrições com respeito a estados e processos em uma organização”.

Surge com isso a necessidade de se modelar regras de negócio, enfatizando a sua importância em um esquema conceitual, que, segundo Loucopoulos, representa todas as regras que governam o universo de discussão, devendo estar definidas dentro de um esquema conceitual.

A partir desta necessidade, tais regras de negócio têm sido amplamente utilizadas pelas organizações como forma de melhorar a qualidade de seus sistemas.

"Regras de Negócio são todas as regras existentes num sistema de informação, que ditam seu comportamento, suas restrições e validações".

"Regras de negócio definem como o negócio funciona, podem abranger diversos assuntos como políticas, interesses, objetivos, compromissos éticos e sociais, obrigações contratuais, decisões estratégicas,leis e regulamentações entre outros".

"Business rules or business rulesets describe the operations, definitions and constraints that apply to an organization in achieving its goals. For example a business rule might state that no credit check is to be performed on return customers. Others could define a tenant in terms of solvency or list preferred suppliers and supply schedules. These rules are then used to help the organization to better achieve goals, communicate among principals and agents, communicate between the organization and interested third parties, demonstrate fulfillment of legal obligations, operate more efficiently, automate operations, perform analysis on current practices, etc."




Regras de Negócio permitem a especificação de políticas, condições ou procedimentos, dentro de um Domínio de Problema, a serem seguidos pelos Processos Organizacionais, para que uma Organização alcance seus objetivos.

Regras de Negócio propiciam o controle (restrição – presente), o planejamento (previsão – futuro) e a explicação (passado).

A separação das regras de negócio nos sistemas de informação apresenta uma série de vantagens amplamente aceitas na comunidade de sistemas de informação [R97, R98, D00].

Segundo [G97] uma regra de negócio pode ser definida segundo duas perspectivas: a perspectiva do negócio e a perspectiva dos sistemas de informação (SI). Segundo a perspectiva do negócio, uma regra de negócio é uma diretiva destinada a influenciar ou guiar o comportamento do negócio, como suporte à política de negócio que é formulada em resposta a uma oportunidade. Segundo a perspectiva dos sistemas de informação, uma regra de negócio é uma sentença que define ou restringe algum aspecto do negócio. Pretende-se garantir a estrutura do negócio ou controlar a influência do comportamento do mesmo.

Ainda, segundo [D00], as regras de negócio são a solução para o problema da necessidade de se escrever código de forma procedural, podendo-se especificar sistemas apenas de forma declarativa. As regras de negócio, segundo ele, nos permitem automatizar o processamento de negócios.

Como dito em [G97] os métodos tradicionais de análise de sistemas por muito tempo tenderam a negligenciar regras de negócio inerentes aos empreendimentos, preocupavam-se principalmente em modelar a estruturação dos dados utilizados e os processos executados pelos empreendimentos.

Os métodos mais modernos de modelagem de sistemas, principalmente os que dão enfoque a orientação a objetos, já tentam lidar e resolver tais problemas. Isto pode ser visto na proposta de extensão a UML[BRJ97] chamada OCL (Object Constraint Language) em [OCL97] para dar suporte a restrições. Date em [D00] vai mais além dizendo que poderíamos até eliminar o processo de codificação de software simplesmente utilizando uma modelagem de sistemas baseado em regras de negócio com sua frase de impacto “declarative is better the procedural” que significa que é melhor que se defina sistemas apenas de forma declarativa e não procedural como é feito hoje em dia.

Uma forma de se conseguir, ao menos em parte, este objetivo, é a formalização das regras de
negócio em uma base de conhecimento. Uma dificuldade na administração das regras de negócios está no fato de que as bases de conhecimento não devem conter incongruências lógicas. Formalizar as regras de negócio utilizando-se uma linguagem declarativa permite que as mesmas sejam convertidas para uma representação em lógica de primeira ordem, o que irá facilmente permitir que tais incongruências sejam identificadas. Mais do que isso, ao se modificar uma regra, ou acrescentar uma nova, a consistência da base poderá ser testada para a verificação de incongruências, de modo listar as regras conflitantes auxiliando a equipe no trabalho de resolver tais problemas. Além disso, a formalização de parte do conhecimento obtido durante a fase de análise é um grande passo na direção de se gerar código automaticamente.

image



Bibliografia

  1. [D00] Date, C. What not How, The Business Rules Approach to Application
    Development, Addison-Wesley, Reading Massachussets, 2000.
  2. [R97] Ross, R. The Business Rules Book: Classifying, Defining, and Modeling Rules
    2nd edition, Business Rule Solutions Inc., Houston Texas, 1997.
  3. [R98] Ross, R. Business Rules Concepts, The New Mechanics of Business
    Information Systems, Business Rule Solutions Inc., Houston Texas, 1998.
  4. [G97] GUIDE Business Rules Project: Final Report, revision 1.2, October 1997.
  5. [BRJ97] Booch, G.; Rumbaugh, J.; Jacobson, I,; “The Unified Modeling Language for
    Object-Oriented Development”, Documentation Set Version, janeiro, 1997.
  6. [OCL97] Object Management Group, “Object Constraint Language Specification”, 1
    September 1997.

domingo, setembro 16, 2007

Critérios de Qualidade do Projeto Conceitual de Banco de Dados



A noção de qualidade do modelo conceitual de dados foi introduzida por Lindland [LiSS94]. O qual citou três tipos de qualidade:

  1. Qualidade semântica é o grau de correspondência entre o modelo conceitual e o mundo real. (expressividade)
  2. Qualidade sintática é o grau de correspondência entre o modelo conceitual e sua representação. (legibilidade, correção)
  3. Qualidade pragmática é o grau de correspondência entre o modelo conceitual e sua aplicabilidade como modelo para situações do mundo real. (completeza, minimalidade, flexibilidade).


Essas três categorias procuram medir a qualidade de um modelo conceitual de dados.

Um modelo conceitual de dados do mundo real ("conceptual world”) procura capturar todos os aspectos essenciais do mundo real ("real world”) independente de qualquer tipo de tecnologia.

O modelo conceitual será representado em uma linguagem ( "symbolic world"), de forma que se possa utiliza-lo como um instrumento para comunicação (projetista x usuário).

Um projetista ou um usuário terá, no entanto, sua própria interpretação do modelo simbólico.
Os critérios de qualidade, anteriormente mencionados, buscam reduzir as inúmeras possibilidades de interpretação.

São os seguintes os critérios de qualidade do Projeto Conceitual de Banco de Dados:

  1. Correção
  2. Completeza
  3. Minimalidade
  4. Expressividade
  5. Legibilidade
  6. Flexibilidade

Ferramenta de Projeto (Modelagem) - Definição




Requisito de Informação - Definição


Requisitos de Informação estabelecem as Informações Necessárias, dentro de um Domínio de Problema, aos Processos Organizacionais, nos diversos Níveis (Estratégico, Tático e Operacional) de uma Organização.