Projeto de Banco de Dados - Estudo de Caso

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

*
Projeto de Banco de Dados
Estudo de Caso: “Sistema para Gerenciamento de uma coleção particular de CDs”
Fonte: Revista SQL Magazine – Edição 58
Profa MsC Josyane Lannes Florenzano de Souza
Centro Universitário Estácio Ceará – FIC
*
Estudo de Caso
Desenvolvido em DBDesigner 4 (opensource) 
link (http://www.fabforce.net/dbdesigner4)
Sistema para gerenciamento de uma coleção particular de Cds
*
Conceitos
Modelo de Banco de Dados: Descrição formal da estrutura de um banco de dados.
Exemplo: O modelo 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
*
Conceitos
Modelo Conceitual: Também uma descrição do banco de dados, porém de uma forma independente da implementação que será feita, quer dizer, independe de qual SGBD será utilizado na implementação.
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.
Exemplo de Modelo Conceitual (Fig 01): 
*
Conceitos
Modelo Lógico: Aproxima-se mais da implementação que será feita
Ele é a abstração no nível do usuário do SGBD (obs: DBA que implementará o BD)
O modelo lógico já é dependente de qual SGBD será implementado. Este modelo descreve a estrutura do BD no nível do SGBD.
Exemplo de Modelo Lógico (Fig 02): 
*
Conceitos
Modelo Físico: Ú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 chaves primária e estrangeira (que já estão no modelo lógico), este modelo contempla definições de armazenamento que não tem influência alguma nas etapas anteriores, mas é crucial no tocante à performance geral de BD.
Exemplo de Modelo Físico (Fig 03): 
*
Notações preferidas pelos arquitetos de dados
Tradicional
EER
Cross Foot (pé de Galinha)
*
Notação Tradicional
Exemplo (Fig 04):
*
Notação EER
Extended Entity-relationship
Entidade Relacionamento Estendido
Estendida da Notação ER (criada em 1976 por Peter Chen)
Exemplo (Fig 05) implementada pelo DBDesigner 4:
*
Notação Cross Foot
(pé de Galinha)
Uma das notações mais utilizadas dentre os arquitetos de dados
*
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 ER, proposta por Peter Chen em 1976. 
Observa-se também uma tendência na utilização de técnicas de OO.
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 PR Chen), a entidade é representada por um retângulo.
Fig 06
*
Entidade
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 determinando CD da coleção, “Dark Side of The Moon” por exemplo, dizemos que esta informação é 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, o relacionamento é representado por um losango, ligado por linhas “as entidades (retângulos). 
Fig 07
*
Relacionamento
Perceba que este modelo representa que queremos manter informações sobre os CDs (conjunto de objetos CD), também queremos manter informações sobre os Artistas (conjunto de objetos Artista) e também que existe uma associação ou relacionamento entre Artista e CD, que nomeados de relacionamento Grava.
Da mesma forma que podemos nos referenciar a uma determinada ocorrência de CD ou Artista, podemos nos referenciar a uma determinada ocorrência do relacionamento Grava, por exemplo podemos dizer que “Pink Floys” grava “Atom Heart Mother”.
Não necessariamente devemos relacionar apenas entidades diferentes. Podemos ter casos em que a Entidade se relacione com ela mesma (auto-relacionamento).
Imagine a entidade Funcionário, que armazena as informações de todos os funcionários da empresa.
Dentro da hierarquia de qualquer empresa existem os gerentes e os gerenciados, porém ambos são funcionários.
Podemos nos referir a este relacionamento como: “Funcionário” gerencia “Funcionário” (auto-relacionamento)
Fig 8
*
Cardinalidade
Cardinalidade Mínima
Cardinalidade Máxima
Fig 9
*
Classificação de relacionamentos
Relacionamento Binários – relacionamento feito entre 2 e somente 2 entidades
Relacionamento Ternário
Fig 10: 1:1
*
Voltando ao Estudo de Caso
Um CD pertencerá a apenas uma Categoria de CD e uma Categoria do CD poderá possuir muitos CDs
Fig 11: 1:n
*
Voltando ao Estudo de Caso
n:n
Num relacionamento n:n, uma ocorrência de uma entidade pode se relacionar com muitas ocorrências de outra entidade e a recíproca
Fig 12
*
Classificação de relacionamentos
Relacionamento Binários
Relacionamento Ternário – 3 entidades se relacionam entre si através do mesmo relacionamento
Fig 13
*
E como fica a cardinalidade neste caso?
*
Cardinalidade
Cada par de ocorrências de “Artista” e “Música” está relacionado a, no máximo, um “CD”;
Já o para de ocorrência de “CD” e “Música” está relacionado a, no máximo, vários “Artistas”;
O par de ocorrências de “CD” e “Artista” está relacionado a, no máximo, várias “Músicas”.
Fig 14
*
Atributos
“Informação associada à entidade ou relacionamento”
Fig 15
Artista
CódigoArtista
Nome
Descrição[0,1]
Fig 16
BandasInfluentes[0,n]
*
Atributos
“Informação associada à entidade ou relacionamento”
Perceba que o “artista” pode ter uma “Função” específica apenas quando “Grava” aquela determinada “Música”, por exemplo atuar como “Backing Vocal” em uma “Música” e como “Tecladista” em outra.
Fica claro que este atributo só estará presente caso haja o relacionamento entre um”Artista” e uma “Música”
*
Conclusão
Vimos nesta parte os conceitos básicos a qualquer Arquiteto de Dados para o projeto de banco de dados;
Estes conceitos são fundamentais para a definição de um projeto dentro das boas práticas de modelagem.