Projeto de Banco de Dados - Parte 1

De que se trata o artigo?
O artigo trata de conceitos fundamentais de modelagem de dados, importantes para todos os Arquitetos de Dados.

Em que situação o tema é útil?
Em todas as situações do cotidiano de um Arquiteto de Dados, o conhecimento das bases fundamentais de modelagem se mostram muito úteis.

Projeto de banco de dados é um tema que nunca sai de moda. Independente do sistema, sempre deve ser iniciado por um bom projeto, uma boa modelagem, pois é justamente à partir deste ponto que será garantida a confiabilidade, eficiência e eficácia de seu sistema.

Muitos dos problemas enfrentados no dia-a-dia de qualquer DBA, na verdade, têm como causa um projeto “mal feito” ou “mal implementado”.

É com base nesta premissa que tomei a liberdade de iniciar este pequeno treinamento, ou mini curso, abordando o tema de projeto de banco de dados.

A ideia é mesclar o acadêmico com a realidade, definindo conceitos, mas também utilizando um estudo de caso real para ilustrar melhor cada definição.

Primeiramente gostaria de agradecer ao Carlos Matsuki, que permitiu que seu estudo de caso publicados nas edições 41, 42, 43 e 44, da coluna Desafio SQL, fosse usado como estudo de caso para esta série. Este estudo de caso é um sistema para gerenciamento da coleção particular de CDs do Carlos, incluindo no sistema o gerenciamento de empréstimos feitos aos seus amigos.

No decorrer desta série, entenderemos todos os passos deste estudo de caso e você perceberá que este é um exemplo que poderá ser aplicado em diversas situações.

Utilizarei também nesta série o software de modelagem DBDesigner 4.

Conceitos Básicos

Invariavelmente, para iniciar qualquer estudo é preciso conhecer os conceitos fundamentais para que o “desenrolar” do estudo tenha um bom alicerce e as “boas práticas” sejam bem utilizadas.

Alguns conceitos que devem estar bem solidificados na “cabeça” do Arquiteto de Dados (Nota DevMan 1):

Nota DevMan 1. Arquiteto de Dados (Data Architect)

O Arquiteto de Dados (Data Architect, em inglês) é o profissional responsável por assegurar que os dados da empresa estejam suportados por uma arquitetura que contemple os objetivos estratégicos. Esta arquitetura deve abranger o banco de dados, integração de dados e a metodologia para acessar estes dados. Geralmente, o Arquiteto de Dados atinge seus objetivos através da padronização dos dados da empresa.

Modelo de Bancos de Dados: é a descrição das informações armazenadas em um banco de dados. Citando como exemplo o nosso estudo de caso, podemos dizer que o modelo de dados informa que o banco de dados armazena informações sobre CDs e que, para cada CD, estão armazenadas informações sobre o autor, título, número de CDs e as músicas. Em resumo, um modelo de banco de dados nada mais é do que a descrição formal da estrutura de um banco de dados;

Modelo Conceitual: já o modelo conceitual é também uma descrição do banco de dados porém de uma forma independente da implementação que será feita, em outras palavras, ele independe de qual SGBD será utilizado na implementação. Desta forma, um mesmo modelo conceitual poderá ser utilizado para implementação em Oracle, DB2, PostgreSQL, etc. O modelo conceitual indica quais os dados que poderão aparecer no banco de dados, mas não informa de que forma estes mesmos dados serão armazenados no nível do SGBD. Em resumo, um modelo conceitual é um modelo abstrato que descreve a estrutura de um banco de dados de forma independente do SGBD. Ainda no nosso estudo de caso, exemplifico um modelo conceitual na Figura 1.

Figura 1. Exemplo de Modelo Conceitual.

Modelo Lógico: o modelo lógico já se aproxima mais da implementação que será feita, ou seja, ele é a abstração no nível do usuário do SGBD (no caso, os DBA que efetivamente implementarão o bd). Podemos concluir que o modelo lógico já é dependente de qual SGBD será implementado. O modelo lógico descreve a estrutura do banco de dados no nível do SGBD. Seguiremos com o exemplo de nosso estudo de caso, conforme Figura 2.

Figura 2. Exemplo de Modelo Lógico.

Modelo Físico: o modelo físico é o último passo antes da geração dos scripts de implementação. Ele é totalmente dependente do SGBD específico que será utilizado. Além das definições de chave primária e chaves estrangeiras (que já estão presentes no modelo lógico), o modelo físico contempla definições de armazenamento que não tem influência alguma nas etapas anteriores, mas é crucial no tocante à performance geral do banco de dados. A Figura 3 apresenta um exemplo, seguindo a mesma linha dos exemplos anteriores.

Figura 3. Exemplo de Modelo Físico.

Notações

De acordo com o dicionário Michaelis: Notação:

1. Ato ou efeito de notar.
2. Sistema de representação ou designação convencional.
3. Conjunto de sinais com que se faz essa representação ou designação.

Em outras palavras, em relação a projetos de bancos de dados, a notação é a forma utilizada para representar determinado modelo.

Algumas notações são as preferidas pelos arquitetos de dados. Dentre elas, citarei três principais que podem ser utilizadas no próprio DBDesigner 4:

Tradicional: a notação tradicional apresenta as entidades através de retângulos, os relacionamentos através de linhas ligando as entidades e pequenos círculos mostrando a cardinalidade do relacionamento. Veja o exemplo desta notação na Figura 4.

Figura 4. Modelo Lógico representado pela notação tradicional.

EER: a notação EER (Extended Entity-Relationship – Entidade-Relacionamento Estendido) é uma notação estendida da notação ER (Entidade-Relacionamento), que foi criada e desenvolvida em 1976 por Peter Chen (Nota DevMan 2) para descrever bancos de dados relacionais. Apresenta as entidades através de retângulos, os relacionamentos através de losangos e um número (ou letra) ao lado da entidade descrevendo a cardinalidade. A Figura 1 mostra um exemplo de um modelo utilizando a notação EER da maneira como ela foi idealizada, porém os software CASE (Computer Aided Software Engineering – Engenharia de Software Auxiliada por Computador) têm uma certa dificuldade em implementar os atributos, desta forma a Figura 5 apresenta o nosso modelo utilizando a Notação EER implementada pelo DBDesigner 4.

Figura 5. Modelo Lógico representado pela notação EER implementada pelo DBDesigner 4.

Nota DevMan 2. Dr. Peter Chen e o modelo ER

Atualmente, os termos “Modelo Entidade-Relacionamento”, “Diagrama Entidade-Relacionamento – DER” e “Peter Chen” são amplamente utilizados em livros, artigos, cursos, páginas web, etc. Digite o termo “Peter Chen” no Google. Lhe retornará aproximadamente 124.000 resultados. Para “Diagrama ER”, você verá aproximadamente 5.660 resultados. E para “Modelo ER”, aproximadamente 19.700 resultados.

Notação Cross Foot (Pé de Galinha): Esta é a notação mais amplamente utilizada dentre os arquitetos de dados. Sua implementação é feita através de retângulos representando as entidades, linhas representando os relacionamentos e traços representando a cardinalidade, onde a cardinalidade “muitos” é representada por um “tridente” aparentando um “pé de galinha”. Esta é a notação que adotei para esta série, cujo exemplo pode ser visto na Figura 2.

Entidade-Relacionamento

O primeiro passo no desenvolvimento de um projeto de banco de dados é a modelagem conceitual, cujo objetivo é identificar a descrição do banco de dados da maneira mais abstrata possível, sem se importar com o SGBD que será utilizado. A técnica mais difundida e amplamente utilizada atualmente é a abordagem Entidade-Relacionamento, proposta por Peter Chen em 1976. Observamos também uma tendência na utilização de técnicas de orientação a objetos, mas definitivamente a modelagem ER ainda é dominante e, particularmente, não acredito que seja substituída tão cedo.

Veremos a seguir os conceitos centrais que são base para a construção de qualquer projeto de banco de dados.

Entidade: o conceito de entidade deve estar bem definido para o arquiteto de dados. Uma entidade, no modelo conceitual, representa um objeto existente na realidade a ser modelada. É importante estar bem fixado que o objetivo do modelo conceitual é justamente modelar de forma abstrata um banco de dados. Perceba que os objetos da realidade modelada podem ser concretos (CD, Artista) ou abstratos (Categoria CD, Gênero Artista). No Diagrama ER (DER – proposto por Chen), a entidade é representada por um retângulo, conforme Figura 6.

Figura 6. Exemplos de Entidades num Diagrama ER.

Perceba que cada retângulo representa um objeto da realidade modelada, e necessariamente um objeto que se queira armazenar informações sobre ele.

Com isso, no nosso exemplo, a entidade “CD” representa o conjunto de todos os CDs existentes na coleção e assim sucessivamente.

Saliento ainda que para referenciar um determinado CD da coleção, “Dark Side of The Moon” por exemplo, dizemos que esta informação é uma “ocorrência” ou “instância” da entidade CD, assim como “Pink Floyd” será uma “ocorrência” ou “instância” da entidade Artista.

Relacionamento: outro importante “objeto” que se deve descrever no modelo conceitual é justamente a associação ou relacionamento existente entre uma entidade e outra.

No DER (Diagrama ER), o relacionamento é representado por um losango, ligado por linhas às entidades (retângulos). A ...