No artigo anterior, finalmente iniciamos a conversão entre os modelos Conceitual e Lógico. Esta é uma parte bastante importante do processo, pois já considera características do SGBD em questão.
Até o momento, executamos apenas o primeiro passo da transformação entre modelos, ou seja, a definição das tabelas com base nas entidades do Modelo Conceitual. As Figuras 1 e 2 mostram este resultado.
Figura 1. Entidades do Modelo Conceitual.
Figura 2. Tabelas do Modelo Lógico.
É importante também, neste momento, definir qual o SGBD que será utilizado e no nosso caso, optei pelo MySQL, por dois motivos simples: 1) é um SGBD Open Source; 2) É a única opção presente no DB Designer para a geração do Modelo Físico e scripts de criação do banco de dados.
Antes de darmos prosseguimento, é importante termos em mente que precisamos chegar, a cada passo, sempre mais perto da implementação final no banco de dados. Por isso, evitaremos também a utilização de acentuação e espaços na definição dos nomes de tabelas e campos. Você verá nas próximas seções as tabelas já devidamente corrigidas.
Neste artigo, continuaremos a tarefa de transformação do Modelo Conceitual em Modelo Lógico (o primeiro passo foi executado na edição anterior da SQL Magazine).
Continuando a transformação - 2º Passo: Atributos do Modelo Conceitual transformando-se em Campos no Modelo Lógico
Já temos a definição das primeiras tabelas, com base nas entidades encontradas no Modelo Conceitual. Passaremos agora para a definição dos campos destas tabelas com base nos atributos encontrados no Modelo Conceitual.
Apenas para relembrar, a Figura 3 mostra o Modelo Conceitual completo e é com base nele que continuaremos a transformação entre modelos. É importante salientar, como você já deve ter notado, que nosso modelo não contempla TODAS as características que possam aparecer em um modelo, mas nem por isso deixarei de cobrir estas características, apenas utilizarei exemplos práticos destas características mas estes exemplos não estarão efetivamente no modelo final.
Figura 3. Modelo Conceitual completo, apresentado pelo Diagrama ER.
Vamos iniciar definindo os campos para as tabelas já definidas sem nos preocupar com os relacionamentos. Estes campos são os atributos das entidades do Modelo Conceitual.
Como devemos levar em consideração o SGBD específico, uma informação importante, mas não fundamental para o Modelo Lógico, é o tipo de dados e o tamanho de cada campo. O Modelo Lógico em si não contempla estas informações, mas quando utilizamos ferramentas CASE para a construção do Modelo Lógico, definir este tipo de informação é particularmente útil, pois já deixa seu Modelo Lógico preparado para a conversão em Modelo Físico. Desta forma mostrarei na Tabela 1 os campos definidos e também os tipos de dados com os respectivos tamanhos. Note que os detalhes de tipo de dados podem variar de acordo com o SGBD escolhido, portanto é muito importante que seja lida a documentação do SGBD escolhido para verificar exatamente os tipos de dados suportados.
|
Entidade |
Atributo |
Tabela |
Campo |
Tipo de Dados |
|
Gênero Artista |
Código |
Gen_Artista |
Codigo |
INTEIRO |
|
Nome |
Nome |
LITERAL(64) | ||
|
Artista |
Código |
Artista |
Codigo |
INTEIRO |
|
Nome |
Nome |
LITERAL(64) | ||
|
Descrição |
Descricao |
LITERAL(128) | ||
|
Ano Origem |
Ano_Origem |
DATE | ||
|
Local Origem |
Local_Origem |
LITERAL(64) | ||
|
Música |
Código CD |
Musica |
Codigo_CD |
INTEIRO |
|
Núm Faixa |
Num_Faixa |
INTEIRO | ||
|
Título |
Titulo |
LITERAL(64) | ||
|
Tipo Gravação |
Tipo_Gravacao |
INTEIRO | ||
|
CD |
Código |
CD |
Codigo |
INTEIRO |
|
Título |
Titulo |
LITERAL(64) | ||
|
Núm CDs |
Num_CDs |
INTEIRO | ||
|
Categoria CD |
Código |
Categoria_CD |
Codigo |
INTEIRO |
|
Nome |
Nome |
LITERAL(64) | ||
|
Usuário |
Código |
Usuario |
Codigo |
INTEIRO |
|
Nome |
Nome |
LITERAL(64) |
Tabela 1. Tabela de conversão das entidades/atributos para tabelas/campos.
A Figura 4 apresenta a posição atual do Modelo Lógico.
Figura 4. Modelo Lógico contendo as entidades/atributos convertidas em tabelas/campos.
3º Passo: Atributos Multi-valorados do Modelo Conceitual transformando-se em Tabelas no Modelo Lógico
Em nosso modelo, conforme a descrição dos requisitos, não houve um caso sequer de atributo multi-valorado, mas o exemplo e implementação é bem simples de ser apresentado em nosso próprio modelo.
Imagine a situação da entidade “Usuário” apresentada na Figura 5.
Figura 5. Entidade “Gravadora” com atributo multi-valorado.
Perceba na Figura 5 o atributo “Telefone” na entidade “Gravadora”. Claramente é um atributo multi-valorado (com cardinalidade mínima 0 e máxima n), pois uma gravadora pode possuir mais de um telefone e deseja-se manter informações, se este for o caso. Temos também o atributo “Endereço” que também é multi-valorado, pois é composto de logradouro, complemento, número e CEP.
Como sabemos, um campo de uma tabela não poderá receber mais de um valor, como é o caso dos famosos vetores (ou arrays, como são conhecidos) das linguagens de programação. Desta forma, atributos multi-valorados serão convertidos em tabelas relacionadas no Modelo Lógico.
Veja na Figura 6 a implementação do exemplo da Figura 5.
Figura 6. Entidade “Gravadora” com atributo multi-valorado.
Perceba na Figura 6 que foram criadas duas tabelas (“End_Gravadora” e “Tel_Gravadora”) relacionadas com a tabela “Gravadora” e que a chave primária (atributo identificador) da tabela “Gravadora” foi definida como chave estrangeira (identificado por FK de Foreign Key) nas duas novas tabelas e, além de ser a chave estrangeira o campo é também parte da chave primária das novas tabelas. Esta implementação de chave estrangeira é o que define o relacionamento entre as tabelas.
...
