AULA 05 – Projeto Lógico e Abordagem Direta

Prévia do material em texto

Perfil: 
Martin José Fagonde Morães. 
Possui Mestrado em Engenharia de Produção pela Universidade Federal 
de Santa Catarina – UFSC (2001), graduado em Processamento de Dados 
(1997). Atua como professor nos componentes curriculares de desenvolvimento 
de sistemas há mais de 15 anos. Foi coordenador de cursos de graduação e de 
pós-graduação. Atuou na área de TI por mais de 18 anos como: coordenador de 
TI, consultor e desenvolveu e implementou sistemas diversos sistemas. 
Currículo Lattes: http://lattes.cnpq.br/2746554350570335 
 
AULA 05 – Projeto Lógico e 
Abordagem Direta 
 
Introdução: 
No projeto lógico, organiza-se o resultado da modelagem conceitual, na 
forma que o SGDB entenda, na forma com que ele deve trabalhar os dados. 
O SGDB escolhido foi o MySQL, é relacional. Sendo assim, o modelo 
lógico que for construído tem de ser um modelo que atenda a abordagem 
relacional. 
Nesta unidade vamos trabalhar a converção do modelo conceitual 
apresentado na Figura 1 DER - Rede de Mensagens. Vamos construir um 
diagrama com a ferramenta MySQL Workbench. O diagrama resultante 
apresenta todas as informações que constam em um DER e todas as 
informações necessárias para o modelo lógico. 
 
Vamos começar conhecendo os principais tipos de dados (domínios) 
disponibilizados no SGDB MySQL. 
Contextualizando 
 
Tipo de Dados - MySQL 
As informações apresentadas neste tópico foram extraídas da 
documentação oficial do MySQL ( ORACLE. MySQL 5.7 Reference Manual. 
Disponível em: <http://dev.mysql.com/doc/refman/5.7/en/>. Acesso em: 12 out. 
2015). 
Neste contexto aparecerá alguns termos que são muito significativos. 
Vamos conhecê-los: 
UNSIGNED: É uma instrução utilizada juntamente com os tipos de dados 
(domínios) numéricos, para definir que o campo em questão não armazenará 
valores negativos. Isto faz com que aumente a capacidade do campo em 
armazenar os valores positivos. 
(1,1) 
(0,n) 
*e-mail 
Usuários 
nome 
Endereço 
Data cadastro 
id senha 
Mensagens 
texto 
imagem 
vídeo 
id 
Envia Grupo 
pertence 
outros 
(1,n) (1,1) 
(1,n) 
(1,n) 
Comentários 
texto Gostou id 
Recebe Faz 
(0,n) 
(1,1) 
(0,n) 
(1,1) 
Comentário do 
comentário 
Faz 
Recebe 
texto Gostou id 
(0,n) 
(1,1) 
Figura 1 DER - Rede de Mensagens. 
SIGNED: Por padrão, todos os tipos (domínios) numéricos são signed, 
esta instrução indica que o campo armazenará valores negativos. 
ZEROFILL: É uma instrução utilizada juntamente com os tipos de dados 
(domínios) numéricos, para definir que o campo em questão terá as casas da 
esquerda preenchidas com zero. Ex.: se a capacidade do domínio definido é de 
três casas e o valor armazenado for de uma casa, as outras duas casas a 
esquerda serão preenchidas com zero. 
NULL: É uma instrução utilizada juntamente com os tipos de dados 
(domínios) para definir que o campo pode ficar sem receber um valor. 
NOT NULL: É uma instrução utilizada juntamente com os tipos de dados 
(domínios) para definir que o campo NÃO pode ficar sem receber um valor. 
 
Tipos numéricos inteiros 
SERIAL 
É um alias for BIGINT UNSIGNED NOT NULL AUTO_INCREMENT 
UNIQUE. 
Um campo que for definido com o tipo “serial” ele receberá as definições 
que o domínio será BIGINT, sem sinal, não pode ser null, o seu valor será 
automaticamente gerado e não se repetirá. 
Tabela resumo de inteiros 
A Tabela 1 mostra os principais domínios (tipos) inteiros do MySQL, com 
a respectiva capacidade. 
Tabela 1 - Tipos inteiros. 
Tipo Armazenado Mínimo Máximo 
 (Bytes) (Signed/Unsigned) (Signed/Unsigned) 
TINYINT 
 
1 -128 127 
 0 255 
SMALLINT 
 
2 -32768 32767 
 0 65535 
MEDIUMINT 
 
3 -8388608 8388607 
 0 16777215 
INT 
 
4 -2147483648 2147483647 
 0 4294967295 
BIGINT 
 
8 -9223372036854775808 9223372036854775807 
 0 18446744073709551615 
 
Tipos numéricos ponto flutuante 
Ao definir um campo do tipo numérico de ponto flutuante tem de indicar 
a precisão e a quantidade de casas decimais. A precisão é o total de casas, 
incluindo as casas decimais. 
 M – Indica o número total de dígitos, precisão. 
 D – Indica a quantidade de casas decimais, ou seja, depois da vírgula. Se D for zero (0) 
não terá casas decimais. 
 
Exemplo: salario Decimal (8,2). => 999999,99 
 Significa que salario será um número com um valor no máximo de oito caracteres 
sendo que dois destes serão de casa decimais. 
 
 DECIMAL[(M[,D])] [UNSIGNED] [ZEROFILL] 
O valor máximo de M é 65. Se omitido o valor padrão é 10. 
Valor máximo para D é 30. Se omitido o valor padrão é zero (0) 
 
São sinônimos para o tipo DECIMAL os tipos: 
 DEC[(M[,D])] [UNSIGNED] [ZEROFILL], 
 NUMERIC[(M[,D])] [UNSIGNED] [ZEROFILL], 
 FIXED[(M[,D])] [UNSIGNED] [ZEROFILL] 
 
 FLOAT[(M,D)] [UNSIGNED] [ZEROFILL] 
Permite valores de 3.402823466E+38 a -1.175494351E-38. 
Se M e D forem omitidos será armazenado até a capacidade permitida 
pelo hardware. 
Precisão de 7 casas decimais, aproximadamente. 
 
 DOUBLE[(M,D)] [UNSIGNED] [ZEROFILL] 
Permite valores de -1.7976931348623157E+308 a -
2.2250738585072014E-308. 
Se M e D forem omitidos será armazenado até a capacidade permitida 
pelo hardware. 
Precisão de 15 casas decimais, aproximadamente. 
São sinônimos para o tipo DECIMAL os tipos: 
 DOUBLE PRECISION[(M,D)] [UNSIGNED] [ZEROFILL], 
 REAL[(M,D)] [UNSIGNED] [ZEROFILL] 
 
Data e Horas 
Chamamos a atenção para o tipo TIMESTAMP, pois o mesmo leva em 
consideração o UTC - Coordinated Universal Time, Isto significa que a data e o 
horário armazenado será convertido conforme a configuração UTC da máquina 
em que está rodando. 
 
Tabela 2 Tipos de data e hora. 
TIPO TAMANHO EXEMPLO INTERVALO 
DATE 3 bytes 'YYYY-MM-DD' '1000-01-01' a '9999-12-31' 
TIME 3 bytes 'HH:MM:SS' '-838:59:59' a '838:59:59' 
DATETIME 8 bytes 'YYYY-MM-DD HH:MM:SS' '1000-01-01 00:00:00' 
a '9999-12-31 23:59:59' 
TIMESTAMP 4 bytes time zone to UTC time zone to UTC 
YEAR 1 byte 'YYYY' de 1901 a 2155 ou 0000 
 
Tipos String 
Os campos destes tipos armazenam todos os tipos de caracteres. Não 
permitem operações aritméticas com seus conteúdos. 
L representa o tamanho em byte padrão para o tipo. 
M representa a quantidade de caracteres definida para a coluna e para 
os tipos não binários, já para os tipos binários representa a quantidade de bytes. 
 
Tabela 3 - Tipos STRING. 
Tipo de dado Tamanho para armazenamento 
CHAR(M) M × w bytes, 0 <= M <= 255, onde w é o número de bytes 
necessários para o tamanho máximo de armazenamento 
de um caractere. 
BINARY(M) M bytes, 0 <= M <= 255 
VARCHAR(M), VARBINARY(M) L + 1 bytes se requerido de 0 − 255 bytes, 
L + 2 bytes se requerido mais que 255 bytes 
TINYBLOB, TINYTEXT L + 1 bytes, para L < 28 
BLOB, TEXT L + 2 bytes, para L < 216 
MEDIUMBLOB, MEDIUMTEXT L + 3 bytes, para L < 224 
LONGBLOB, LONGTEXT L + 4 bytes, para L < 232 
 
Tipo BOOL, BOOLEAN 
O tipo boolean é sinônimo para TINYINT(1). O valor zero (0) é 
considerado “false” e um valor diferente de zero (0) é considerado “true”. 
 
Estudo de Caso: Rede de Mensagens 
Vamos converter o DER da modelagem da Rede de Mensagens, Figura 
1 DER - Rede de Mensagens. em um modelo lógico utilizando a ferramenta 
MySQL Workbench. 
O diagrama que será gerado na criação do modelo lógico atende as 
especificações da abordagem ER e as especificações da abordagem relacional. 
Com frequência estes diagramas são referenciados também como DER. 
Os relacionamentos estão indicados com linhas e as cardinalidades com 
a notação de Martin e Finkelstein, denominada“pés de galinha”, veja a 
equivalência entre as notações de cardinalidade na Figura 2 Equivalência entre 
notações. 
 
Figura 2 Equivalência entre notações. 
Descrição Notação Peter Chen Notação Martin e Finkelstein 
Mín. e Máx.: 1 | 
Mínima: 0 o 
Máxima: N 
 
Na notação Martin e Finkelstein o símbolo mais próximo a tabela é a 
cardinalidade máxima e o símbolo mais interno é a cardinalidade mínima. 
 
Convertendo a entidade Usuário 
A entidade é convertida em tabela, os atributos em campos, o atributo 
identificador é convertido em campo chave. Os nomes de cada elemento são 
adequados as especificações dos caracteres aceitos. 
 
 
 
Convertendo a entidade Mensagem 
A entidade é convertida em tabela, os atributos em campos, o atributo 
identificador é convertido em campo chave. Os nomes de cada elemento são 
adequados as especificações dos caracteres aceitos. 
Os atributos imagem e vídeo serão armazenados no campo “iva”, um 
acrônimo para Imagem, Vídeo e Áudio. Na especificação, no modelo conceitual, 
não indica a utilização de áudio. Considerando que o tipo que definimos para o 
campo comporta qualquer tipo de arquivo, vamos considerar no acrônimo o “a”. 
*e-mail 
Usuários 
nome 
Endereço 
Data cadastro 
id 
Figura 3 Entidade Usuário para Tabela usuario.. 
 
 
O relacionamento entre Usuários e Mensagens 
O relacionamento “envia” entre usuário e mensagens indica uma 
cardinalidade máxima de 1:n, para esta situação a recomendação é adicionar 
uma coluna em mensagem, para ser uma chave estrangeira referenciando o 
usuário que enviou a mensagem. 
Veja na Erro! Fonte de referência não encontrada., foi criada a coluna 
“usuario_idusuario” com a indicação de chave estrangeira. A indicação do 
relacionamento está apresentada pela linha que liga as duas tabelas e a 
representação da cardinalidade que estamos usando é a notação “pé de 
galinha”. 
 
Figura 5 Relacionamento envia mensagem 
 
 
Comentários da mensagem 
Vamos converter a entidade Comentários na tabela “comentario”. Para 
o atributo “Gostou” definimos o campo “gostou” do tipo boolean. O tipo boolen 
Figura 4 Entidade Mensagens para Tabela mensagem. 
com os seus três estados, será aplicado “true” para gostou, “false” para não 
gostou e o “null” para sem manifestação. 
 
 
 
 
 
 
 
 
Relacionamentos com “comentario” 
No relacionamento da tabela mensagem com a tabela comentario a 
cardinalidade máxima é 1:n, o indicativo é a criação de mais um campo na tabela 
comentário, para ser a chave estrangeira com o referido registro na tabela 
mensagem. O campo criado foi mensagem_idmensagem. 
No relacionamento da tabela usuario com a tabela comentario a 
cardinalidade máxima, também é 1:n, o indicativo é a criação de mais um campo 
na tabela comentário, para ser a chave estrangeira com o referido registro na 
tabela mensagem. O campo criado foi usuario_idusuario. 
 
Figura 7 Relacionamentos com comentário. 
 
Figura 6 Entidade Comentários na tabela comentario. 
Comentário do Comentário 
A entidade “Comentário do comentário” vamos converter em tabela 
“comentariodo”. Os atributos seguem as mesmas considerações para a tabela 
comentário. 
 
 
 
Relacionamentos com “comentariodo” 
Os relacionamentos e as cardinalidades mantem-se, seguem os 
mesmos princípios. Considerando que as duas cardinalidades máximas são 1:n 
foram criados dois campos para serem chaves estrangeiras, um para comentário 
e outro para o usuário que fez o comentário do comentário. 
Figura 9 Relacionamentos do comentáriodo. 
 
Figura 8 Entidade comentário do comentário em tabela comentariodo. 
Identificando os usuários do mesmo grupo. 
O relacionamento de usuários com usuários, onde um usuário pode estar 
relacionado a vários outros usuários e que os outros usuários podem estar 
relacionados a vários usuários, nos dá um relacionamento com cardinalidade 
n:n, o indicado é a criação de uma nova tabela, vamos criar a tabela “grupo”. 
Todo novo usuário tem a obrigatoriedade de estar em um grupo, seu 
próprio grupo. 
Figura 10 Grupo usuários. 
 
 
 
Pesquisa 
Agora que acabou de ver a criação de um modelo lógico, identifique 
conversando com profissionais da área, representações de modelo lógico e 
identifique as notações de cardinalidade e os efeitos das chaves estrangeiras. 
Trocando Ideias 
Compartilhe com os colegas, através do fórum, suas observações e 
conclusões quanto as chaves estrangeiras e as cardinalidades nas situações 
que você identificou. 
Síntese 
O modelo lógico criado com estas notações, permite uma visualização 
clara e limpa, mantendo as representações das cardinalidades, os tipos dos 
dados para cada campo, as tabelas/entidades existentes e outros recursos 
fundamentais. Esta notação também permite uma visualização com as 
características de um DER. 
Os tipos de dados do MySQL são muito semelhantes a outros SGDB, 
com isto o modelo lógico construído pode ser implementado em diferentes 
SGDB. 
Com habilidades bem desenvolvidas e utilizando ferramentas como 
MySQL WorkBench, muitos profissionais implementam a modelagem conceitual 
e lógica na mesma etapa e obtendo resultados muito bons. 
Compartilhando 
Considere o contexto do ensino superior de matrículas, professores, 
componentes curriculares, períodos e etc., e utilizando o MySQL WorkBench 
faça a modelagem conceitual e lógica na mesma fase. Apresente-o para um 
colega e juntamente validem o modelo. 
 
Referências 
HEUSER, Carlos Alberto (Org.). Projeto de banco de dados. 6. ed. Porto Alegre (RS): Bookman, 
2009.xii, 282. 
KROENKE, David M. (Org.). Banco de Dados: Fundamentos, Projeto e Implementação. 6. ed. 
Rio de Janeiro - RJ: LCT, 1999.