Planeje o seu Modelo de Dados

Uma das fazes do projeto de desenvolvimento é a modelagem de dados, planeje qual banco de dados vai usar e o que vai usar em cada banco de dados, sendo ele ORACLE, MS SQL, DB2 e etc.

por Thiago Cruz

1.3 Esquemas e Instâncias

Em qualquer modelo de dados é importante distinguir entre descrição da base de dados da própria base de dados. A descrição de uma base de dados é chamada Esquema da Base de Dados. Um esquema de base de dados é especificado durante o projeto da base de dados, sendo que a expectativa de mudanças não é grande. A forma de visualização de um esquema é chamada Diagrama do Esquema. Muitos modelos de dados têm certas convenções para, diagramaticamente, mostrar esquemas especificados no modelo.

Os dados atualmente existentes em uma base de dados podem mudar com relativa freqüência. Os dados da base de dados em um particular momento do tempo são chamados Instâncias da Base de Dados (ou Ocorrências ou Estados). A base-esquema é algumas vezes chamada de Base-Intencional e uma instância é chamada de Base-Extensional do esquema.

2) Arquitetura e Independência de Dados de SGBD’s

2.1 Arquitetura “Three-Schema” (conhecida como arquitetura ANSI/SPARC - Tsichritzis e Klug, 1978)

A meta desta arquitetura é separar as aplicações de usuários da base de dados física. Nesta arquitetura, esquemas podem ser definidos em três níveis:

a. O nível interno tem um esquema interno que descreve a estrutura de armazenamento físico da base de dados. O esquema interno usa um modelo de dados físico e descreve todos os detalhes de armazenamento de dados e caminhos de acesso à base de dados;

b. O nível conceitual tem um esquema conceitual que descreve a estrutura de toda a base de dados. O esquema conceitual é uma descrição global da base de dados, que omite detalhes da estrutura de armazenamento físico e se concentra na descrição de entidades, tipos de dados, relacionamentos e restrições. Um modelo de dados de alto-nível ou um modelo de dados de implementação podem ser utilizados neste nível.

c. O nível externo ou visão possui esquemas externos ou visões de usuários. Cada esquema externo descreve a visão da base de dados de um grupo de usuários da base de dados. Cada visão descreve, tipicamente, a parte da base de dados que um particular grupo de usuários está interessado e esconde o resto da base de dados do mesmo. Um modelo de dados de alto-nível ou um modelo de dados de implementação podem ser usados neste nível.


fig. 1.: Ilustração da separação da base de dados do usuário
Muitos SGBD’s não separam os três níveis completamente. Pode acontecer que alguns SGBD’s incluam detalhes do nível interno no esquema conceitual. Em muitos SGBD’s que dão suporte à visões, os esquemas externos são especificados com o mesmo modelo de dados usado no nível conceitual. Note-se que os três esquemas são apenas descrições dos dados. 3) Independência de dados

Neste artigo procuro passar alguns conceitos importantes antes de entrar a fundo no modelo de dados. No desenvolvimento de um sistema ou de vários sistemas, é necessário gerenciar o banco de dados, que consiste em uma coleção de dados inter-relacionados. Um conjunto de dados, normalmente referenciado como “banco de dados”, contém informações sobre uma ou várias empresas. Seu principal objetivo é prover um ambiente adequado e eficiente para recuperar, armazenar e tratar informações. Pensando no gerenciamento destes dados envolvendo: definição das estruturas de armazenamento, técnicas de manipulação e maneiras de garantir a segurança dos dados, desenvolvi esse artigo baseando na necessidade da modelagem de dados.

4) Modelagem de Dados Usando o Modelo Entidade-Relacionamento (MER)

O MER é um modelo de dados conceitual de alto-nível. Assim, os conceitos do MER foram projetados para serem compreensíveis a usuários, descartando detalhes de como os dados são armazenados.
Atualmente, o MER é usado principalmente durante o processo de projeto da base de dados. Existem expectativas para que uma classe de SGBD’s baseados diretamente no MER esteja disponível no futuro.


fig. 2.: Ilustração conceitual de um Modelo de Dados

5) Conceitos do Modelo Entidade-Relacionamento

5.1 Entidades e Atributos

O objeto básico que o MER representa é a entidade. Uma entidade é algo do mundo real que possui uma existência independente. Uma entidade pode ser um objeto com uma existência física - uma pessoa, carro ou empregado - ou pode ser um objeto com existência conceitual - uma companhia, um trabalho ou um curso universitário. Cada entidade tem propriedades particulares, chamadas atributos, que o descrevem. Por exemplo, uma entidade empregado pode ser descrita pelo seu nome, o trabalho que realiza, idade, endereço e salário. Uma entidade em particular terá um valor para cada um de seus atributos. Os valores de atributos que descrevem cada entidade ocupam a maior parte dos dados armazenados na base de dados.

A figura abaixo ilustra duas entidades. A entidade EMPREGADO e1 tem quatro atributos: Nome, Endereço, Idade e Telefone residencial. Os seus valores são: “Renato Cleber”, R. 123 de Março, Belo Horizonte, MG, 30120-012”, “33” e “3321-2020”, respectivamente. A entidade companhia c1 tem três atributos: Nome, Sede e Presidente. Seus valores são: “Nonato Neves”, “Betim”, “Ricardo Chaves”.


fig. 3.: Ilustração com exemplo de entidades e atributos
Alguns atributos podem ser divididos em subpartes com significados independentes. Por exemplo, Endereço da entidade e1 pode ser dividido em Endereço da Rua, Cidade, Estado e CEP. Um atributo que é composto de outros atributos mais básicos é chamado composto. Já, atributos que não são divisíveis são chamados simples ou atômicos. Atributos compostos podem formar uma hierarquia:


fig. 4.: Ilustração com exemplo de entidades e atributos compostos
Atributos compostos são úteis quando os usuários referenciam o atributo composto como uma unidade e, em outros momentos, referenciam especificamente a seus componentes. Se o atributo composto for sempre referenciado como um todo, não existe razão para subdividi-lo em componentes elementares.

6) Diagrama Entidade-Relacionamento (DER)

A figura 5 ilustra um DER para o esquema da base de dados COMPANHIA. Os tipos de entidades tais como EMPREGADO, DEPARTAMENTO e PROJETO são mostrados em retângulos. Tipos de relacionamentos tais como TRABALHA-PARA, GERENCIA, CONTROLA e TRABALHA-EM são mostrados em losângulos interligados à tipos de entidades participantes. Atributos são mostrados em elipses conectadas à tipos de entidades ou relacionamentos. Os atributos-chaves são sublinhados.


fig. 5.: Ilustração do modelo conceitual desenvolvido no VISIO 2002
Clique aqui e visualize o modelo de dados acima no Visio 2002, salvo para visualização em WEB.

Na figura 5 são mostradas as razões de cardinalidade para cada tipo de relacionamento binário. A razão de cardinalidade de DEPARTAMENTO:EMPREGADO em GERENCIA é 1:1, para DEPARTAMENTO:EMPREGADO em TRABALHA-PARA é 1:N e M:N para TRABALHAEM. As restrições de participação parcial são especificadas por linhas simples. As linhas paralelas denotam participação total (dependência existencial).

7) O Modelo de Dados Relacional

O Modelo de Dados Relacional foi introduzido por Codd(1970). Entre os modelos de dados de implementação, o modelo relacional é o mais simples, com estrutura de dados uniforme e o mais formal.

7.1 Conceitos do Modelo Relacional

O modelo de dados relacional representa os dados da base de dados como uma coleção de relações. Informalmente, cada relação pode ser entendida como uma tabela ou um simples arquivo de registros.
Por exemplo, a base de dados de arquivos representada pela figura 6, é considerada estar no modelo relacional. Porém, existem diferenças importantes entre relações e arquivos.


fig. 6.: Ilustração de um Modelo Relacional
O nome da tabela e os nomes das colunas são usados para ajudar a interpretar o significado dos valores em cada linha da tabela. Por exemplo, na figura anterior, a primeira tabela é chamada ESTUDANTE porque cada linha representa o fato sobre uma particular entidade estudante. Os nomes das colunas - Nome, Número, Classe, Departamento - especificam como interpretar os valores em cada linha baseando-se nas colunas que cada um se encontra. Todos os valores de uma mesma coluna são, normalmente, do mesmo tipo.

8) Modelo físico

Nessa etapa serão desenhadas as estruturas lógicas do modelo Dimensional, com as definições de tabelas fatos e tabelas dimensão, relacionamentos, indexação, atributos de tabelas e implantação de regras. Nesse momento a equipe projetista deverá considerar o uso do SGBD Relacional da instalação como depósito das informações do armazém de dados, ou o uso de um SGBD Dimensional, caso essa seja a opção. Terminada a fase de especificação das estruturas dimensionais, no plano conceitual, passamos a definir as tabelas dentro do ambiente de gerência de Banco de Dados até atingir o estágio físico do projeto de modelagem de dados. Vários aspectos relacionados ao projeto físico de Banco de Dados deverão ser considerados para garantir performance no acesso às estruturas relacionais ou dimencionais.
No seu planejamento procure preocupar com os seguintes itens para um bom desempenho da sua aplicação:

Dicas: Como escrever comandos em SQL:

Conclusão