Manual básico de modelagem de dados

1. Introdução

1.1 Evolução no tratamento dos dados
 

1.1.1 Primeira fase

Nesta fase os dados são tratados por aplicação. Somente a aplicação possui acesso aos dados, pois a estrutura dos registros encontra-se definida no código fonte da aplicação. Por causa disso os problemas de tratamento (acesso) dos dados, comuns a qualquer aplicação, precisam ser resolvidos (administrados) pela própria aplicação.

1.1.2 Segunda fase

Sendo uma evolução da primeira fase e forçada pela necessidade dos usuários, nesta segunda fase os dados continuam sendo armazenados em arquivos e tratados por aplicação. No entanto já há uma preocupação dos desenvolvedores em integrar as aplicações possibilitando a troca de dados entre elas.

1.1.3 Terceira fase

Visando isolar os dados das aplicações facilitando o acesso aos mesmos e por consequência a integração dos sistemas, na terceira fase começam a surgir os primeiros SGBDs. Os sistemas gerenciadores passam a assumir algumas funções que antes eram de responsabilidade da aplicação, como por exemplo, a definição das estruturas dos arquivos (tabelas).

1.1.4 Quarta fase

A quarta fase constitui a última geração dos SGBDs. A proposta destes sistemas é promover uma completa abstração dos dados. Os SGBDs assumem todo o controle e tratamento, restando para a aplicação apenas a necessidade de se comunicar com o gerenciador requisitando consultas. Os problemas de acesso concorrente, segurança, consistências e integridade passam a ser de responsabilidade do banco de dados, abrindo caminhos para a construção de sistemas melhores e tempos cada vez menores.

1.2 Razão para a evolução

Em poucas palavras podemos justificar a necessidade de evolução na forma como os dados são tratados afirmando que os dados são recursos estratégicos para um empresa.

Um sistema de banco de dados proporciona à empresa um controle centralizado de seus dados operacionais. Os dados são um dos ativos mais valiosos que uma empresa pode ter. Em caso de sinistro é preferível que se perca todo o patrimônio da empresa, mas se preservem os dados. Sendo tão importantes assim, os dados merecem tratamento especial.

1.3 Consequências do uso de SGBD

A integração e compartilhamento dos dados gerou grandes benefícios, mas criou novas necessidades. O próprio conceito de independência de dados (imunidade das aplicações com relação aos dados) reforçou a necessidade de níveis de abstração de dados. 

Benefícios:

· Economia de espaço de armazenamento;
· Economia do esforço de desenvolvimento;
· Redução da redundância de dados;
· Redução da inconsistência de dados.

Necessidades: 

· Maior uniformidade;
· Ampliar dispositivos de segurança (restrições de acesso e responsabilidades sobre a manutenção de dados);
· Reforçar padrões;
· Manter a integridade.

2. Abstração de dados

Um SGBD deve dar ao usuário uma visão abstrata dos dados, escondendo detalhes de armazenamento e manutenção, pois a complexidade interna das estruturas de armazenamento não interessam ao usuário.

Abstração de dados, portanto, é a capacidade de enxergar a realidade desprezando certos detalhes que, no momento, são irrelevantes. são estabelecidos cinco níveis para efeito de estudos sobre este assunto. O primeiro nível é a própria realidade, seguida por quatro níveis de abstração.

2.1 Projeto descendente - top down

É um método para derivar os modelos de cima para baixo. Inicialmente elabora-se um projeto  lógico para só então derivar o projeto físico. Os passos enumerados abaixo orientam a elaboração de um projeto descendente. O primeiro e o segundo passos correspondem ao projeto lógico, enquanto que o terceiro passo corresponde ao projeto físico.

Primeiro passo: elaborar um modelo descritivo a partir de observações e vivências do mundo real.
Segundo passo: derivar um modelo conceitual a partir do modelo descritivo.
Terceiro passo: derivar um modelo operacional a partir do modelo conceitual, que será introduzido no computador.

2.2 Projeto ascendente - bottom up

É um método para gerar o modelo operacional partindo dos próprios dados que serão introduzidos no computador. No projeto ascendente aplicam-se técnicas que visam ajudar a definir quais dados são relevantes para a organização, bem como suas formas de armazenamento. Estas técnicas, quando bem empregadas, geram modelos operacionais idênticos (ou iguais) aos gerados pelo método descendente, ou seja, sem redundâncias. Os seguintes passos orientam a construção de um projeto ascendente.

Primeiro passo: fazer um levantamento completo de todos os dados operacionais da empresa a partir de documentos utilizados no mundo real.
Segundo passo: aplicar as técnicas de normalização sobre as relações de dados extraídas dos documentos.
Terceiro passo: construir o modelo conceitual a partir do modelo operacional. Este passo, por razões de conveniência, pode não ser de interesse da empresa.

3. Projetos descendentes

3.1 Modelo conceitual

3.1.1 Conceito

O modelo conceitual é um nível de abstração utilizado para  representar os elementos que compõem a realidade do usuário, bem como os relacionamentos entre estes componentes.

3.1.2 O que deve ser descrito pelo modelo conceitual?

O modelo conceitual deve descrever o conhecimento útil e relevante da realidade, como fatos, fenômenos individuais, entidades ou relacionamentos, de forma concreta e concisa. Exemplo: “Fornecedor F fornece peças do tipo P para o projeto J”.

O exemplo acima revela um fato concreto de fenômeno classificado como conjunto de entidades. Um conhecimento abstrato é uma informação que amplia nossa interpretação da informação concreta e nos permite fazer inferências e conclusões sobre outros fatos. Este tipo de conhecimento é indesejável para o modelo conceitual. Exemplo: “Num dado dia, um funcionário pode atuar em somente um projeto”. “Qualquer fornecedor fornece ao menos duas peças para cada projeto”.

3.1.3 Semântica do modelo de dados conceitual

A semântica inerente aos dados deve ser uma preocupação atendida pelo modelo conceitual. Sempre que possível o modelo conceitual deve capturar o máximo de semântica da realidade, pois a semântica diz respeito ao significado dos dados.

3.1.4  Requisitos para modelos conceituais

Deve ser elaborado com a participação do usuário:
· Evitar a tendência de usar representações e conceitos computacionais;

· O usuário conhece melhor a realidade;
· Modelos conceituais devem ser naturais, de alto nível e orientados para a solução dos problemas do usuário, de maneira que incentive sua participação.

Deve servir de base para discussão e negociação:
·  O modelo conceitual mostrará uma forma de enxergar a realidade;
·  O usuário deve opinar e discutir com o analista a cerca do grau de abstração desejado;
·  As regras e restrições devem ser negociadas com o usuário;

Deve servir de base para o projeto de um banco de dados eficiente em computador. 

3.2 Modelo conceitual de entidades e relacionamentos 

O modelo E-R foi criado baseado na teoria dos conjuntos, visando incorporar informações semânticas sobre o mundo real em uma forma de representação que garante a independência de dados e que facilmente deriva modelos operacionais. 

·  Proposto por Peter Chen em 1976;
·  Mundo real consiste de entidades e relacionamentos;
·  Incorpora importantes informações semânticas sobre o mundo real;

·  Baseado na teoria dos conjuntos;
·  Possui alto grau de independência de dados;
·  Modelos operacionais são facilmente derivados. 

3.2.1 Elementos e conceitos estabelecidos pelo modelo E-R

Entidade: é uma representação abstrata de um “objeto” do mundo real.

Conjunto de entidades: grupo de entidades com características semelhantes, como por exemplo, o conjunto de funcionários. Os conjuntos de entidades são representados por retângulos no modelo E-R. Cada objeto do mundo real é representado por uma só entidade de um único conjunto de entidades, para evitar redundâncias.

Atributos: informações a cerca de uma entidade. São representados no modelo ao redor do conjunto de entidades.

Relacionamentos: são associações entre duas ou mais entidades, que representam um fato ou uma solução do mundo real. Exemplo: João está lotado no departamento de vendas.

Domínio: o domínio de um atributo é o conjunto de valores admissíveis para este atributo. O atributo sexo, por exemplo, pode ter como domínio o conjunto {M,  F}. Já o atributo código pode ter como domínio um intervalo de valores [1; 999].

Formalmente, atributo é a função que mapeia um conjunto de entidades em um conjunto de valores (domínio).

3.2.2 Restrições de relacionamento

3.2.2.1 Cardinalidade

Expressa o número de instâncias de uma entidade que podem ser associadas a uma instância (ocorrência, tupla, registro) de outra entidade através do relacionamento.

Uma para muitos: uma entidade em A está associada a qualquer número de entidades em B. Uma entidade em B pode estar associada a, no máximo, uma entidade em A.

Um para um: uma entidade em A está associada a, no máximo, uma entidade em B. E uma entidade em B está associada com no máximo uma entidade em A.

Muitos para muitos: uma entidade em A está associada a qualquer número de entidades em B. Uma entidade em B está associada a qualquer número de entidades em A.

3.2.2.2 Parcialidade/totalidade ou obrigatoriedade/opcionalidade

Seja E um conjunto de entidades e R um conjunto de relacionamentos em que E participa. Se todo elemento de E deve estar obrigatoriamente em R, então R é total em E, caso contrário, R é parcial em E.

Esta restrição (restrição de participação) especifica se a participação de uma entidade em um relacionamento será total ou parcial.

· Total: todas as instâncias participam do relacionamento.

· Parcial: algumas instâncias participam do relacionamento.

3.2.2.3  Persistência

Bloqueia a remoção de instâncias das entidades envolvidas em um determinado relacionamento, que estejam participando de alguma instância desse relacionamento.

3.2.3 Características de implementação do modelo E-R

3.2.3.1 Auto-relacionamento

É aquele que associa elementos de um conjunto de entidades a elementos deste mesmo conjunto de entidades.

3.2.3.2 Sinônimos para conjuntos de entidades (papéis ou roles)

Uma entidade pode, conforme o caso, assumir diferentes papéis num modelo de dados.

3.2.3.3 Relacionamentos múltiplos

3.2.3.4 Agregações

A agregação é uma abstração onde um relacionamento de muitos para muitos é tratado como uma entidade de um nível mais alto. Implementa a representação de um relacionamento entre uma entidade e um relacionamento de muitos para muitos.

3.2.3.5 Particionamento ou generalização ou especialização

Conjunto de entidades que representam elementos do mundo real que se subdividem em categorias com atributos parcialmente distintos.

Generalização: mecanismo onde atributos comuns a entidades de mais baixo nível são representadas um única vez em uma entidade de mais alto nível.

Especialização: atributos adicionais, presentes em apenas alguns objetos da entidade (especializações) são representados em entidades de mais baixo nível.

3.3 Modelo operacional

O modelo operacional é responsável por detalhar todos os aspectos necessários para implementação do projeto. Devem ser descritas todas as tabelas ou relações necessárias, seus atributos e regras ou restrições de acesso aos dados. O nível de detalhe ao qual se deve chegar depende do ambiente de desenvolvimento adotado pela empresa. Normalmente descreve-se tudo que é necessário (ou  requisitado) para operacionalizar o modelo no banco de dados usado pela organização.

3.3.1 Conversão do modelo conceitual para o operacional

Para gerar o modelo conceitual podemos utilizar diversas técnicas e diagramas, contudo, se este fora modelado utilizando o diagrama de entidades e relacionamentos, a conversão para o modelo operacional torna-se natural.

No modelo conceitual de entidades e relacionamentos utilizamos conjuntos de entidades, relacionamentos, atributos e alguns símbolos para representar a semântica pertinente a tabelas, tuplas e regras operacionais. Veja como esta conversão se dá:

A próxima figura explicita melhor estes elementos do modelo operacional.

3.3.1.1 Chave primária

Para cada tabela (relação) devemos eleger um chave primária. A chave primária é composta por um ou mais atributos que permitem uma identificação única de cada tupla da tabela. Para tal seleciona-se os atributos ou conjunto de atributos que reúnem esta característica, os quais são chamados de chaves candidatas. Entre as chaves candidatas escolhe-se o atributo que melhor desempenha o papel de chave primária para assumir esta função, assim sendo, as demais chaves passam a ser consideradas chaves alternativas. Na ausência de um atributo (ou conjunto de atributos) que se qualifique para assumir o papel de chave primária, cria-se um novo atributo com esta característica. Normalmente este atributo recebe nomes como: código, matrícula, número, sigla, etc.

As tabelas (relações) inicialmente são enumeradas juntamente com a lista de seus atributos, como mostra o exemplo abaixo. Para destacar a chave primária costuma-se sublinhar os atributos que a compõem. Exemplo de representação no modelo operacional: Produto (CódProduto, Descrição, PreçoUnitário, Estoque)

3.3.1.2 Chave estrangeira

No modelo operacional relacional as tabelas se relacionam através de atributos comuns. Duas tuplas estão relacionadas quando a chave primária (um ou mais atributos) da primeira tupla estiver presente na segunda tupla. Veja o exemplo abaixo.

NotaFiscal (NúmeroNF, DataEmissão, ValorTotal, CódigoCliente)
Cliente (CódigoCliente, Nome, Endereço, Telefone)

Cada tupla da relação NotaFiscal se relaciona com uma tupla da relação Cliente, pois na realidade do usuário uma nota fiscal sempre é emitida para um cliente. Para explicitar este relacionamento a relação NotaFiscal contém dentre a lista de seus atributos o atributo CódigoCliente, que é a chave primária da relação cliente. Assim sendo, o atributo CódigoCliente pertencente à tabela NotaFiscal (necessário para estabelecer o relacionamento) é considerado chave estrangeira na relação NotaFiscal. Normalmente estes atributos recebem um sinal # para melhor identificá-los. NotaFiscal (NúmeroNF, DataEmissão, ValorTotal, CódigoCliente#)

3.3.1.3 Relacionamentos de um para um 

Este tipo de relacionamento é o mais fácil de ser convertido para o modelo operacional. Após definidas as duas tabelas com suas chaves primárias, basta acrescentar a chave primária de uma delas como chave estrangeira na outra tabela.

3.3.1.4 Relacionamentos de um para muitos

Os relacionamentos de um para muitos também são facilmente convertidos para o modelo operacional. Neste caso a chave primária da tabela onde os relacionamentos são unívocos deve ser acrescentada na tabela onde os relacionamentos são múltiplos. Veja o mesmo exemplo já utilizado anteriormente.

NotaFiscal (NúmeroNF, DataEmissão, ValorTotal, CódigoCliente#)
Cliente (CódigoCliente, Nome, Endereço, Telefone)

Neste caso as tuplas da relação Cliente podem se relacionar com várias tuplas da relação NotaFiscal, mas cada tupla da relação NotaFiscal só se relaciona com uma tupla da relação Cliente, ou seja, é um relacionamento de um para muitos. Portanto a chave primária da relação Cliente deve figurar na relação NotaFiscal como chave estrangeira.

3.3.1.5 Relacionamentos de muitos para muitos

Alguns bancos de dados não implementam relacionamentos de muitos para muitos. Por causa disto devemos converter os relacionamentos deste tipo para dois relacionamentos de um para muitos.

Após realizada esta conversão aplicam-se os mesmos procedimentos já descritos nos tópicos anteriores.

3.3.2 Dicionário de dados

O dicionário de dados nada mais é do que uma descrição detalhada de todos os dados que envolvem uma aplicação. A construção de um dicionário de dados pode ser um trabalho exaustivo e ocasionalmente complicado se optarmos por descrever absolutamente todos os dados frutos de uma análise de um sistema, pois muitas metodologias geram um grandiosíssimo volume de dados.

No entanto o dicionário de dados é provavelmente um dos resultados mais importantes que devem sair de um projeto de banco de dados, pois nele serão definidas importantíssimas informações para o gerenciamento da base de dados e consequentemente para a construção dos futuros sistemas de informação.

Para cada atributo de cada relação devemos definir nome interno, tipo, tamanho, domínio, entidade relacionada, valor default, se pode ou não receber valor nulo, etc. A construção do dicionário de dados deve ser baseada nas características do software de banco de dados existente na organização, mas nada impede que se inclua outras informações.

Veja um exemplo simples:

4. Projetos Ascendentes

4.1 Introdução

De maneira inversa aos projetos descendentes, os projetos ascendentes partem da realidade operacional do usuário aplicando sobre os dados existentes na empresa uma técnica de projeto de banco de dados conhecida como normalização.

A normalização é efetuada a partir das informações (dados) extraídas dos documentos comumente utilizados pelo usuário, caracterizando-se como um processo altamente formal.

4.2 Normalização

Normalização é uma técnica de projeto de banco de dados que visa, a partir dos dados existentes na organização, construir relações (tabelas) livres de redundância e passíveis de ser implementadas em um banco de dados relacional.

Para normalizar um conjunto de dados devemos aplicar sobre os mesmos as regras que os tornam normalizados. O processo de normalização passa por diversas etapas conhecidas como formas normais. Veja um exemplo abaixo.

Seja a seguinte relação não normalizada: Funcionários (Código Funcionário, Nome, Endereço, Cidade, UF, CEP, Departamento, (Código Curso, Curso, Data, Grau))

Observação: os  atributos Código Curso, Curso, Data e Grau estão entre parênteses porque se repetem muitas vezes na ficha do funcionário.

4.2.1 Primeira forma normal

Uma relação estará na primeira forma normal se e somente se todos os seus atributos possuírem valores atômicos (únicos).

Funcionários (Código Funcionário, Nome, Endereço, Cidade, UF, CEP, Departamento) 

CursosFuncionário (Código Funcionário#, Código Curso, Curso, Data, Grau)

Observação: os atributos que se repetem (valores não únicos) formam uma nova relação. A chave primária da primeira relação (relação origem) deve ser levada para a nova relação. Para a nova relação devemos definir uma chave primária.

4.2.2 Segunda forma normal

Uma relação estará na segunda forma normal se e somente se estiver na primeira forma normal e todos os seus atributos forem dependentes funcionais de toda a chave primária, ou seja, nenhum atributo pode ser dependente parcial da chave primária.

Funcionários (Código Funcionário, Nome, Endereço, Cidade, UF, CEP, Departamento)
CursosFuncionário (Código Funcionário#, Código Curso#, Data, Grau)

Cursos (Código Curso, Curso)

Observação: o atributo Curso é dependente apenas de Código Curso, por isso foi retirado e passou a integrar uma nova tabela de Cursos onde o atributo que gera a dependência funcional, Código Curso, é trazido como chave primária.

4.2.3 Terceira forma normal

Uma relação estará na terceira forma normal se e somente se estiver na segunda forma normal e nenhum de seus atributos for dependente transitivo da chave primária, ou seja, nenhum atributo pode depender de outro atributo que não é chave.

Funcionários (Código Funcionário, Nome, Endereço, CEP#, Departamento)
Cidades (CEP, Cidade, UF)
CursosFuncionário (Código Funcionário#, Código Curso#, Data, Grau)
Cursos (Código Curso, Curso)

Observação: os atributos Cidade e UF além de dependerem da chave primária Código Funcionário são dependentes do atributo CEP, portanto passam a constituir uma nova tabela tendocomo chave primária o CEP.

4.2.4 Quarta forma normal

Uma relação estará na quarta forma normal se e somente se estiver na terceira forma normal e nenhum de seus atributos for dependente multivalorado da chave primária, ou seja, possuir um conteúdo comum a muitas tuplas da relação.

Funcionários (Código Funcionário, Nome, Endereço, CEP#, Código Depto#)
Cidades (CEP, Cidade, UF)
CursosFuncionário (Código Funcionário#, Código Curso#, Data, Grau)
Cursos (Código Curso, Curso)
Deptos (Código Depto, Departamento)

Observação: o  atributo Departamento é dependente multivalorado do Código Funcionário, pois ele ocorre repetidamente em várias tuplas da relação Funcionário. Para solucionar esta dependência cria-se uma nova tabela com o atributo Departamento, gerando um novo atributo para constituir a chave primária desta nova tabela, Código Depto.