Banco de Dados BD_03 (01)
Modelagem de Dados 02 de fevereiro de 2005
Gabriel Issa Jabra Shammas
MODELAGEM DE DADOS
● Relação de siglas utilizadas neste trabalho: SI: Sistema de Informação
1 MODELAGEM
1.1. Considerações sobre Modelagem de Dados
A Modelagem de Dados (Análise de Dados) é um mecanismo formal proposto para representar graficamente todos os dados necessários para fornecer, a uma Organização, informações que contribuam para o seu sucesso.
O Modelo de Dados começou a ser objeto de estudo quando foram percebidas as inúmeras anomalias que existiam nas bases de Dados (ou nos arquivos convencionais), em virtude de terem sido mal projetadas. As bases de dados eram mal projetadas (e, infelizmente, ainda o são) porque os projetos de bases de dados eram realizados voltados para o ambiente físico (linguagem de programação, gerenciador de base de dados, método de acesso) e não para a forma como os dados são utilizados pelo Negócio.
Dentre os problemas causados por essas anomalias, destacam-se a redundância descontrolada de dados, as dificuldades para a manutenção de Sistemas de Informação (SIs), a inflexibilidade para gerar consultas e relatórios não planejados e o trauma que causam as migrações de ambiente de base de dados.
Atualmente, este tipo de anomalia em particular (a migração de ambiente de base de dados) é muito frequente, com a conversão de bases e arquivos antigos para Sistema Gerenciador de Banco de Dados Relacionais (SGBDr), causando grandes distúrbios nas organizações, por não existirem Modelos de Dados independentes da implementação.
Assim, alguns modelos foram propostos para tentar modificar esta situação. Estes modelos estão mais próximos da realidade do Negócio do que do armazenamento físico; no entanto, permitem que sejam facilmente implementados no computador.
O Modelo de Dados é, portanto, um filtro (ou um conversor) do mundo real dos dados da Organização para o mundo do computador.
Como todo modelo, ele não representa a verdade de forma total e nem consegue abordar todas as questões ligadas aos dados, mas, com certeza, mentem muito menos do que os modelos voltados para o ambiente físico.
Cientes desta necessidade, alguns cientistas propuseram teorias e técnicas para suportar o desenvolvimento de Sistemas e a Administração de Dados. Dentre elas, destacam-se a Teoria da Normalização e o Modelo Entidade-Relacionamento, que se tornaram muito conhecidos e são as mais utilizadas no mercado.
A modelagem pode ser de software, sistema ou de dados.
A Modelagem de Dados (Análise de Dados) é um mecanismo formal proposto para representar graficamente todos os dados necessários para fornecer, a uma Organização, informações que contribuam para o seu sucesso.
A modelagem:
a)“é uma parte central de todas as atividades que levam à implantação de um bom software” [BOOCH, 2000, p. 3]; b)“é uma técnica de engenharia aprovada e bem-aceita” [BOOCH, 2000, p. 6].
“Qualquer projeto será beneficiado pelo uso de algum tipo de modelagem” [BOOCH, 2000, p. 7].
Por que fazer a modelagem?
A verdade é que construímos modelos para compreender melhor o sistema que estamos desenvolvendo”
[BOOCH, 2000, p. 6].
“Para desenvolver software de qualidade duradoura, será necessário criar uma arquitetura de fundação sólida que aceite modificações” [BOOCH, 2000, p. 3]
“Quanto mais complexo for o sistema, maior será a probabilidade de ocorrência de erros ou de construção de itens errados, caso não haja qualquer modelagem” [BOOCH, 2000, p. 7].
“Com a modelagem, alcançamos 4 objetivos:
a) os modelos ajudam a visualizar o sistema como ele é ou como desejamos que ele seja; b) os modelos permitem especificar a estrutura ou o comportamento de um sistema; c) os modelos proporcionam um guia par a construçào do sistema;
d)os modelos documentam as decisões tomadas” [BOOCH, 2000, p. 6]. “Com o auxílio da modelagem:
a)“delimitamos o problema que estamos estudando, restringindo nosso foco a um único aspecto por vez”
[BOOCH, 2000, p. 7];
b)“somos capazes de ampliar o intelecto humano. Um modelo escolhido de maneira adequada permitirá a quem usa a modelagem trabalhar em níveis mais altos de abstração” [BOOCH, 2000, p. 7].
“A modelagem permite a compreensão de um sistema” [BOOCH, 2000, p. 14].
O resultado da modelagem de dados é o modelo de dados.
Pode-se dizer que o Modelo de Dados é um filtro (ou um conversor) do mundo real dos dados da Organização para o mundo do computador.
O Modelo de Dados Conceitual é uma representação gráfica dos principais dados da Organização com elevado grau de abstração.
Ele pode ser Departamental ou Corporativo.
O Modelo de Dados Conceitual Departamental representa os dados de apenas uma Área de Negócios (ou de um departamento).
O Modelo de Dados Conceitual Corporativo representa os dados de toda uma Organização ou de duas ou mais Áreas de Negócios (ou departamentos).
O Modelo de Dados Lógico promove uma descrição dos componentes do Modelo de Dados Conceitual, aproximando-o do ambiente computacional, onde deverá ser trabalhado. A descrição pode ser feita utilizando-se o Dicionário de Dados, que é uma ferramenta muito útil nestes casos.
1.2. Considerações adicionais sobre modelagem
O modelo:
a)“é uma simplificação da realidade” [BOOCH, 2000, p. 6];
b)“fornece uma cópia do projeto de um sistema” [BOOCH, 2000, p. 6];
c)“pode abranger planos detalhados, assim como planos mais gerais com uma visão panorâmica do sistema considerado” [BOOCH, 2000, p. 6].
“Um bom modelo inclui aqueles componentes que têm ampla repercussão e omite os componentes menores que não são relevantes em determinado nível de abstração” [BOOCH, 2000, p. 6].
“Os modelos podem ser:
a) estruturais, dando ênfase à organização do sistema;
b)comportamentais, dando ênfase à dinâmica do sistema” [BOOCH, 2000, p. 6]. Construímos modelos para:
a)“comunicar a estrutura e o comportamento desejados do sistema” [BOOCH, 2000, pp. 3-4]; b)“visualizar e controlar a arquitetura do sistema” [BOOCH, 2000, p. 4];
c)compreender melhor o sistema que está sendo elaborando, muitas vezes expondo oportunidades de simplificação e reaproveitamento [BOOCH, 2000, p. 4];
d)“gerenciar os riscos” [BOOCH, 2000, p. 4].
“Nenhum modelo é inteiramente suficiente” [BOOCH, 2000, p. 14].
“Sempre serão necessários vários modelos, conectados entre si, para tornar possível entender qualquer aspecto, ainda que seja o sistema mais trivial” [BOOCH, 2000, p. 14].
“Construímos modelos de sistemas complexos porque não é possível compreendê-los em sua totalidade”
[BOOCH, 2000, p. 7].
“Todos os sistemas podem ser descritos sob dferentes aspectos, com a utilização de modelos distintos, e cada modelo será, portanto, uma abstração semanticamente específica do sistema” [BOOCH, 2000, p. 6].
“Modelos explícitos facilitam a comunicação” [BOOCH, 2000, p. 15].
A modelagem pode ser textual ou gráfica.
“O texto é uma forma maravilhosamente mínima e direta para escrever expressões e algoritmos” [BOOCH, 2000, p. 14].
“Abstração é a característica essencial de uma entidade que a diferencia de todos os outros tipos de entidades. Uma abstração define uma fronteira relativa à perspectiva do observador” [BOOCH, 2000, p. 449].
A experiência no uso de modelos sugere 4 princípios básicos de modelagem:
a)A escolha dos modelos a serem criados tem profunda influência sobre a maneira como um determinado problema é atacado e como uma solução é definida [BOOCH, 2000, p. 8].
Ou seja, deve-se escolher bem os modelos com que se vai trabalhar.
Cada visão de mundo conduz a um tipo diferente de sistema, com custos e benefícios diversos [BOOCH, 2000, p. 9].
Assim, como exemplo, construindo um sistema a partir da perspectiva de:
i) um desenvolvedor de banco de dados: tende-se a atribuir o foco a modelos de relacionamentos entre entidades, cujo comportamento tente a privilegiar procedimentos armazenados e os eventos que os iniciam [BOOCH, 2000, p. 8];
ii) um analista de análise estruturada: tende-se a usar modelos centrados em algoritmos, com o respectivo fluxo de dados de um processo para outro [BOOCH, 2000, p. 9];
iii) um desenvolvedor orientado a objetos, tende-se a trabalhar com um sistema cuja arquitetura estará centrada em várias classes e os padrões de interação que determinarão como essas classes funcionarão em conjunto [BOOCH, 2000, p. 9].
b)“cada modelo poderá ser expresso em diferentes níveis de precisão” [BOOCH, 2000, p. 9].
Os melhores tipos de modelos serão aqueles que permitem a escolha do grau de detalhamento, dependendo de quem esteja fazendo a visualização e por que deseja fazê-la” [BOOCH, 2000, p. 9].
c)“Os melhores modelos estão relacionados à realidade” [BOOCH, 2000, p. 9].
Será melhor utilizar modelos que tenham uma clara conexão com a realidade e, nos casos em que essa conexào seja fraca, saber, de maneira exata, como esses modelos diferem do mundo real [BOOCH, 2000, p. 9].
Todos os modelos simplificam a realidade; o segredo será ter certeza de que sua simplificaçào não ocultará detalhes importantes [BOOCH, 2000, p. 9].
“O tendão de Aquiles das técnicas estruturadas está no fato de não haver uma conexão básica entre o modelo de análise e o modelo de projeto do sistema. Falhando a ponte sobre essa fenda, ao longo do tempo aparecerá uma divergência entre o sistema concebido e o sistema construído [BOOCH, 2000, p. 10].
d)“Nenhum modelo único é suficiente. Qualquer sistema não-trivial será melhor investigado por meio de um pequeno conjunto de modelos quase independentes” [BOOCH, 2000, p. 10].
“Quase independentes” significa modelos que possam ser criados e estudados separadamente, mas que continuam inter-relacionados [BOOCH, 2000, p. 10].
“Cada tipo de modelo é organizado de modo diferente e cada um tem seu próprio foco.” [BOOCH, 2000, p. 11].
“(...) no caso de sistemas que utilizam muitos dados, predominarão modelos voltados para a visão estática do projeto. Em sistemas centrados no uso de GUI, são importantes as visões estáticas e dinâmicas dos casos de uso. Em sistemas de execução crítica em tempo real, a visão dinâmica do processo tende a ser mais importante. (...) Em sistemas distribuídos, como aqueles encontrados em aplicações que utilizam a Web, os modelos de implementação e de implantação são os mais importantes.” [BOOCH, 2000, p. 10].
“No caso de software, existem várias maneiras de se definir um modelo. As duas maneiras mais comuns são provenientes da perspectiva de um algoritmo ou da perspectiva orientada a objetos.” [BOOCH, 2000, p. 11].
“A visão tradicional no desenvolvimento de software adota a perspectiva de um algoritmo. Nessa visão, o principal bloco de construção do software é o procedimento ou a função. Essa perspectiva conduz os desenvolvedores a voltar o seu foco de atenção para questões referentes ao controle e à decomposição de algoritmos maiores em outros menores. (...) tendência a permitir sistemas instáveis. À medida que os requisitos se modificam e o sistema cresce, será difícil fazer a manutenção de sistemas construídos a partir
“A visão contemporânea no desenvolvimento de software adota uma perspectiva orientada a objeto. Nessa visão, o principal bloco de construção de todos os sistemas de software é o objeto ou a classe. Explicando de uma maneira simples, um objeto é alguma coisa geralmente estruturada a partir do vocabulário do espaço do problema ou do espaço da solução; uma classe é a descrição de um conjunto de objetos comuns. Todos os objetos têm uma identidade (você pode atribuir-lhes nomes ou diferenciá-los dos demais objetos de alguma maneira), um estado (costuma haver dados a eles associados) e um comportamento (você poderá fazer algo com o objeto ou ele poderá fazer algo com outros objetos) [BOOCH, 2000, p. 11].
“A UML é uma linguagem padrão para a elaboração da estrutura de projetos de software” [BOOCH, 2000, p. 13].
“A UML poderá ser empregada para a visualização, a especificação, a construção e a documentação de artefatos que façam uso de sistemas complexos de software” [BOOCH, 2000, pp. 13-14].
“A UML é adequada para a modelagem de sistemas, cuja abrangência poderá incluir sistemas de informação corporativos a serem distribuídos a aplicações baseadas em Web e até sistemas complexos embutidos de tempo real” [BOOCH, 2000, p. 13].
O que é necessário pra compreender a UML?
Para compreender a UML é necessário o entendimento de 3 principais elementos [BOOCH, 2000, p. 13]: a) os blocos básicos de construção da UML;
b) as regras que determinam como esses blocos de construção deverão ser combinados; c) alguns mecanismos básicos que se aplicam a toda a linguagem;
Qual é a relação entre a UML e o processo? A UML é independente do processo [BOOCH, 2000, p. 13].
“As linguagens fornecem um vocabulário e as regras para a combinação de palavras desse vocabulário com a finalidade de comunicar algo” [BOOCH, 2000, p. 14].
“Contexto é um conjunto de elementos relacionados para um determinado propósito, como especificar uma operação” [BOOCH, 2000, p. 451].
“Dependência é um relacionamento semântico entre dois itens, em que a alteração de um item (o item independente) poderá afetar a semântica do outro item (um item dependente)” [BOOCH, 2000, p. 451].
“Escopo é o contexto que dá significado a um nome” [BOOCH, 2000, p. 453].
“Especificação é uma declaração textual da sintaxe e da semântica de um bloco de construção específico; uma descrição declarativa do que alguma coisa é ou faz” [BOOCH, 2000, p. 451].
“Estado é uma condição ou situação durante a vida de um objeto, durante a qual ele satisfaz alguma condição, realiza uma atividade ou aguarda algum evento” [BOOCH, 2000, p. 453].
“Evento é a especificação de uma ocorrência significativa, que tem uma localização no tempo e no espaço; no contexto de uma máquina de estados, o evento é a ocorrência de um estímulo capaz de ativar a transição
“Generalização é um relacionamento de especialização/generalização, em que objetos do elemento especializado (o filho) podem ser substituídos para objetos do elemento generalizado (o pai)” [BOOCH, 2000, p. 454].
“Herança é o mecanismo pelo qual elementos mais específicos incorporam a estrutura e o comportamento de elementos mais gerais” [BOOCH, 2000, p. 454].
“Implementação é uma realização concreta do contrato declarado por uma interface; a definição de como algo é construído ou computado” [BOOCH, 2000, p. 453].
“Integridade é como as coisas se relacionam, umas com as outras, de maneira apropriada e consistente”
[BOOCH, 2000, p. 454].
“Nível de abstração é um lugar na hierarquia de abstrações, abrangendo desde os níveis mais altos de abstração (muito abstratos) até os mais baixos (muito concretos)” [BOOCH, 2000, p. 456].
“Refinamento é um relacionamento que representa a especificação completa de algo já especificado em um determinado nível de detalhe” [BOOCH, 2000, p. 457].
“Relacionamento é uma conexão semântica entre elementos” [BOOCH, 2000, p. 457].
“Sistema é possivelmente decomposto em uma coleção de subsistemas, um conjunto de elementos organizados para a realização de um propósito específico e descrito por um conjunto de modelos, provavelmente sob diferentes pontos de vista” [BOOCH, 2000, p. 457].
“Subsistema é um agrupamento de elementos, em que alguns constituem uma especificação do comportamento oferecido pelos outros elementos contidos nesse agrupamento” [BOOCH, 2000, p. 458].
“Thread é um fluxo leve de controle que pode ser executado concorrentemente com outras threads no mesmo processo” [BOOCH, 2000, p. 458].
“Visão é a projeção em um modelo, vista a partir de uma determinada perspectiva ou ponto de vantagem e omite as entidades que não são relevantes para essa visão” [BOOCH, 2000, p. 459].
2 REFERÊNCIAS BIBLIOGRÁFICAS
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. Trad. Fábio Freitas. Rio de Janeiro: Campus, 2000.
