Modelagem de bases de dados relacionais: Analisando alternativas de apoio - Parte 1

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (1)  (0)

O objetivo deste artigo, dividido em duas partes, é descrever e analisar as formas de implementação do conjunto das principais atividades que devem ser seguidas quando do projeto de modelagem e de implementação de bases de dados relacionais.

capaSQL12.JPG

Clique aqui para ler todos os artigos desta edição

Modelagem de bases de dados relacionais

Analisando alternativas de apoio – Parte 1

 

Uma base de dados bem projetada é a chave para a obtenção de sistemas computacionais eficientes e de boa aceitação.

No início do desenvolvimento de uma base de dados, os projetistas não devem se preocupar com detalhes de implementação, tais como: quantidade de tabelas, campos, tamanho e tipo de cada um dos campos, stored procedures e visões, deixando também para uma segunda etapa a decisão de qual será o SGBD que irá implementá-la. O foco principal ao se iniciar um projeto de base de dados é o entendimento correto das regras do negócio, deixando-se o tratamento das questões físicas para as últimas etapas do projeto.

Nesse sentido, há uma série de atividades a serem desenvolvidas nas tarefas de modelagem e de implementação de uma base de dados. Pode-se dizer que, se o seu projetista seguir esse conjunto de atividades, a probabilidade da obtenção de uma base de dados que atenda a seus requisitos será muito grande.

Aliado a isso, como em outras áreas da Engenharia de Software, foram construídas diversas ferramentas de auxílio à modelagem e implementação de bases de dados a partir desse conjunto de atividades.

O objetivo deste artigo, dividido em duas partes, é descrever e analisar as formas de implementação do conjunto das principais atividades que devem ser seguidas quando do projeto de modelagem e de implementação de bases de dados relacionais. Para cada atividade será realizada uma avaliação de três ferramentas CASE (Computer Aided Software Engineering) (ERwin 4.0, DB-MAIN 7.0 e DBDesigner 4.0) a fim de avaliar se tais ferramentas fornecem apoio satisfatório. A escolha da ferramenta ERwin 4.0 justifica-se pelo fato de que é considerada uma das primeiras e mais conhecidas ferramentas de modelagem do mercado. A ferramenta DB-MAIN 7.0 é uma das ferramentas que melhor representam o modelo de dados, respeitando os conceitos de modelagem, além de ser um software livre para modelos de dados com até 100 objetos. E a ferramenta DBDesigner 4.0 é um software totalmente livre e de fácil acesso. O artigo expõe o que as ferramentas oferecem, deixando para o leitor realizar uma análise crítica de qual é a melhor ferramenta para o projeto que pretenda desenvolver.

A Figura 1 apresenta as principais atividades relacionadas à modelagem e implementação de bases de dados relacionais. Estas consistem em identificar, modelar e implementar um modelo conceitual, de forma consistente, de acordo com as necessidades dos usuários definidas na especificação de requisitos.

 

Figura 1. Seqüência para Aplicação das Atividades de Modelagem.

 

Essa figura também apresenta uma possível seqüência a ser utilizada para a realização das atividades.

A arquitetura mais encontrada na literatura apresenta uma base de dados sendo composta por três níveis ou modelos: externo, lógico e físico. Por uma questão didática, este artigo considera o modelo lógico sendo composto pelos modelos interno e conceitual, conforme apresentado na Figura 2. Com isso, pode-se notar quatro níveis ou modelos: externo, conceitual, interno e físico.

 

Figura 2. Arquitetura de uma Base de Dados Relacional.

 

O modelo externo representa o modo como os usuários finais observam a base de dados.

O modelo conceitual descreve a estrutura da base de dados. A base para a modelagem dos dados é o modelo conceitual, por isso, esse é o ponto de partida para o processo de modelagem lógica dos dados. Inicialmente, o modelo conceitual é representado pelo modelo entidade-relacionamento (modelo ER ou MER), proposto por Peter Chen na década de 70.

O modelo interno, também chamado representativo ou de implementação, fornece conceitos que podem ser compreendidos por usuários finais e, ao mesmo tempo, representam o modo como os dados estão armazenados no computador. Alguns detalhes sobre o modo de armazenamento são escondidos mas, mesmo assim, podem ser implementados em uma base de dados de forma direta.

Os modelos de dados físicos descrevem o modo como os dados são armazenados no computador. Constituem a etapa de mais baixo nível de uma implementação de uma base de dados, contemplando aspectos referentes a: formatos e ordenamento de registros, modos de implementação de indexação, etc. A questão dos modelos físicos não é alvo deste artigo.

Uma primeira constatação a respeito das ferramentas CASE analisadas diz respeito à nomenclatura que cada ferramenta utiliza para designar tais formas ou tipos de modelos. É importante destacar que o modelo conceitual de uma base de dados, no ERwin 4.0, corresponde ao modelo lógico, enquanto que o modelo interno corresponde ao modelo físico. A interface da ferramenta ERWIN 4.0 é apresentada na Figura 3.

 

Figura 3. Aparência da ferramenta CASE ERwin 4.0.

 

O modelo conceitual, no DB-MAIN 7.0, corresponde ao esquema conceitual, enquanto que o modelo interno "

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?