Edição atual tal como às 08h35min de 27 de novembro de 2015

Apresentação

Caro Aluno,

Estamos chegando ao final. Este será nosso último encontro da unidade curricular Desenvolvimento de Sistemas WEB I, espero encontrá-los numa próxima unidade, no próximo ano. Na semana que passou, mostramos mais conjunto de programas chamado XAMPP, formado pelos aplicativos MySQL, Apache, PHP, entre outros. Apresentamos também, a instalação do PostgreSQL e a sua ferramenta administrativa o pgAdmin3. Nesta reta final, vamos falar um pouco sobre modelagem de dados, com destaque para os tipos de dados que o banco de dados MySQL suporta. Assistam os vídeos, façam os exemplos utilizando, preferencialmente, o MySQL Workbench ou DBDesigner. Fiquem atentos aos prazos, a AO2 termina com esta última semana.

Bons estudos a todos!

Prof. Douglas A.

Objetivo

Apresentar a modelagem de dados: modelo conceitual, modelo lógico e físico.
Apresentar os tipos de dados utilizados no MySQL.
Apresentar um passo a passo da geração do código SQL no DBDesigner e Workbench.

Vídeos

Banco de Dados: https://www.youtube.com/watch?v=p0zCY9cKrJM
Modelagem de Dados - Projeto de um Banco de Dados: https://www.youtube.com/watch?v=G-XOc8LVZIo

Textos

Modelagem de dados: http://www.luis.blog.br/modelagem-de-dados-modelo-conceitual-modelo-logico-e-fisico.aspx
Modelo entidade e relacionamento://www.luis.blog.br/modelo-de-entidade-e-relacionamento-mer.aspx
Tipos de Campos no MySQL: http://www.rcoli.com.br/2012/08/tipos-de-campos-no-mysql-saiba-como-escolher-o-tipo-correto/
Armazenando Imagens no MySQL: http://www.devmedia.com.br/armazenando-imagens-no-mysql/32104

Modelagem de dados

A modelagem de dados é uma técnica usada para a especificação das regras de negócios e as estruturas de dados de um banco de dados. Ela faz parte do ciclo de desenvolvimento de um sistema e é de vital importância para o bom resultado do projeto. Modelar dados consiste em desenhar o sistema de informações, concentrando-se nas entidades lógicas e nas dependências lógicas entre essas entidades.

Modelagem de dados ou modelagem de banco de dados envolve uma série de aplicações teóricas e práticas, visando construir um modelo de dados consistente, não redundante e perfeitamente aplicável em qualquer SGBD moderno.

Modelo conceitual

A modelagem conceitual basea-se no mais alto nível e deve ser usada para envolver o cliente, pois o foco aqui é discutir os aspectos do negócio do cliente e não da tecnologia. Os exemplos de modelagem de dados vistos pelo modelo conceitual são mais fáceis de compreender, já que não há limitações ou aplicação de tecnologia específica. O diagrama de dados que deve ser construído aqui é o Diagrama de Entidade e Relacionamento, onde deverão ser identificados todas as entidades e os relacionamentos entre elas. Este diagrama é a chave para a compreensão do modelo conceitual de dados. A Figura 1 mostra um exemplo simples de Diagrama de Entidade e Relacionamento.

Figura 1 - Diagrama de Entidade e Relacionamento.

Modelo lógico

O modelo lógico já leva em conta algumas limitações e implementa recursos como adequação de padrão e nomenclatura, define as chaves primárias e estrangeiras, normalização, integridade referencial, entre outras. Para o modelo lógico deve ser criado levando em conta os exemplos de modelagem de dados criados no modelo conceitual. A Figura 2 mostra um exemplo do diagrama de banco de dados gerado.

Figura 2 - Diagrama de Banco de Dados.

Modelo físico

No modelo físico fazemos a modelagem física do modelo de banco de dados. Neste caso leva-se em conta as limitações impostas pelo SGBD escolhido e deve ser criado sempre com base nos exemplos de modelagem de dados produzidos no item anterior, modelo lógico.

Conclusão

Os detalhes da modelagem mostrados são apenas exemplos práticos de modelagem. Existe outras abordagens que devem ser levadas em consideração, o assunto é extenso e nem sempre de fácil compreensão, mas com um pouco de prática fica mais fácil o entendimento.

Modelo de Entidade e Relacionamento (MER)

O modelo de entidade e relacionamento é o mais utilizado atualmente, devido a sua simplicidade e eficiência. Baseia-se na percepção de mundo real, que consiste em uma coleção de objetos básicos, chamados entidades e relacionamentos entre esses objetos. Você poderá usar ou não um software para modelagem de dados.

A modelagem de dados consiste em uma série de análises conceituais e lógicas para encontrar a melhor disposição possível de armazenamento e manutenção das informações no banco de dados. A modelagem envolve um profundo estudo de caso, seguido da análise de projeto, que pode ser dividida em duas etapas:

Análise de Entidades.
Análise de Relacionamentos.

Na análise de entidades o objetivo é identificar os elementos com algum significado próprio, tais como Clientes, Produtos, Pedidos, Locação, etc. A entidade pode ser algo concreto como Clientes e Produtos ou algo abstrato como Locação e Venda.

Na análise de relacionamentos o objetivo é definir como e quando as entidades se relacionam, isto é particularmente importante a fim de dar maior entendimento do problema.

Outro fator importante é o diagrama de entidade e relacionamento que representa gráficamente o modelo de entidade e relacionamentos, este diagrama pode ser feito com o uso de ferramenta de modelagem de dados ou usando algum programa gráfico. Os softwares para modelagem de dados são alternativas mais interessantes em função da produtividade, organização do seu diagrama de entidade e relacionamento e facilidade de modificações.

Vamos usar o exercício proposto no post (Modelagem conceitual: modelo conceitual de dados) para criar dele o modelo de entidade e relacionamento, isto será feito em duas etapas. Veremos nos posts (Usando a Análise de Entidade: Atributos simples, compostos e multivalorados) e depois no (Relacionamento entre entidades: tipos e cardinalidade).

Análise de Entidades

Entidade é aquele objeto existente no mundo real, com uma identificação distinta e significado próprio. São as coisas que existem no negócio, ou ainda, que descrevem o negócio em si. Se algo existe e proporciona algum interesse em manter dados sobre ele, isto caracteriza como uma Entidade do negócio.

Desta forma, podemos dizer que uma entidade será uma tabela em nosso banco de dados. Na verdade quando identificamos todas as entidades, estaremos definindo quais serão as tabelas que teremos que criar em nosso banco de dados.

Fulano de Tal, CPF nº 111.111.111-22, é uma entidade, uma vez que só pode existir uma única pessoa com o mesmo nome e CPF.

Em um banco de dados de uma empresa, por exemplo, são entidades: Cliente, Funcionário, Departamento, fornecedor, etc. Cada entidade representa objetos com as mesmas características. Um banco de dados, portanto, compreende uma coleção de conjuntos de entidades do mesmo tipo.

A análise de entidade e seus atributos é parte de um estudo maior, o chamado Modelo de entidade e relacionamento, onde são analisados também os relacionamentos existente entre entidades.

Atributos

São propriedades (características) que identificam as entidades. Uma entidade é representada por um conjunto de atributos. Os atributos podem ser simples, composto, multivalorado ou determinante.

Nome, endereço, telefone e cidade, por exemplo, são atributos da entidade Clientes. Enquanto que salário, cargo e departamento são atributos da entidade funcionários.

Existem quatro tipos de atributos: simples, composto, multivalorado e determinante

Atributo Simples

Não possui qualquer característica especial. A maioria dos atributos serão simples. Quando um atributo não é composto, recebe um valor único como nome, por exemplo e não é um atributo chave, então ele será atributo simples.

Atributo Composto

O seu conteúdo é formado por vários itens menores. Exemplo: Endereço. Seu conteúdo poderá ser dividido em vários outros atributos, como: Rua, Número, Complemento, Bairro, Cep e Cidade. Este tipo de atributo é chamado de atributo composto. Veremos mais de sua aplicação no post sobre normalização de dados.

Atributo Multivalorado

O seu conteúdo é formado por mais de um valor.

Exemplo: Telefone. Uma pessoa poderá ter mais de um número de telefone. É indicado colocando-se um asterisco precedendo o nome do atributo. O atributo multivalorado serão tratados com mais detalhes na normalização de dados.

Atributo Determinante

Identifica de forma única uma entidade, ou seja, não pode haver dados repetidos.

É indicado sublinhando-se o nome do atributo. Exemplo: CNPJ, CPF, Código do fornecedor, Número da matrícula, etc. Os atributos determinantes serão as chaves primárias no banco de dados e seu uso tem implicações na normalização de dados.

Análise de Relacionamentos

Relacionamento entre entidades é o tipo de ocorrência existente entre entidades e aplicáveis no processo de modelar dados. Entender isso é importante pois um modelo consistente é a base para um banco de dados de sucesso. O símbolo que representa o relacionamento no Modelo de Entidade e Relacionamento (MER) é um losango com o nome do relacionamento escrito no seu interior, como no exemplo a seguir.

Em um modelo de entidade e relacionamento, nem todas as entidades serão relacionadas, há casos em que não há ligação entre elas, nestes casos consideramos como entidades isoladas. Embora não seja tão comum, é importante levar em conta esta possibilidade. Mas quando as ligações existirem, elas serão classificadas de acordo com os tipos a seguir. Tipos de relacionamento

Existem três tipos de relacionamento entre entidades:

um-para-um
um-para-muitos
muitos-para-muitos

Relacionamento um-para-um

O relacionamento um-para-um é usado quando uma entidade A se relaciona com uma entidade B e vice-versa.

Este relacionamento é representado pelo sinal: 1:1

Veja o exemplo:

Relacionamento um-para-muitos

O relacionamento um-para-muitos é usado quando uma entidade A pode se relacionar com uma ou mais entidades B.

Este relacionamento é representado pelo sinal: 1:N

Veja o exemplo:

Relacionamento muitos-para-muitos

O relacionamento muitos-para-muitos é usado quando várias entidades A se relacionam com várias entidades B.

Este relacionamento é representado pelo sinal: N:N ou N:M

Veja o exemplo:

Cardinalidade

A cardinalidade é um conceito importante para ajudar a definir o relacionamento, ela define o número de ocorrências em um relacionamento.Para determinar a cardinalidade, deve-se fazer a pergunta relativa ao relacionamento em ambas as direções.

Um departamento possui quantos empregados?

- no mínimo 1 e no máximo N.

Um empregado está alocado em quantos departamentos?

- no mínimo em 1 e no máximo em 1

Somando-se as cardinalidades, definimos o resultado final do relacionamento, ou seja, 1:N.

Tipos de campos no MySQL

O desenvolvedor inexperiente costuma confundir bastante os tipos de campo da linguagem utilizada (PHP por exemplo) com os tipos que o banco pode armazenar. Um exemplo clássico dessa confusão é o booleano que é automaticamente convertido de true para 1 e false para 0 (zero). Além disso, há o clássico erro de armazenamento de CPF em campo numérico o que faz com que todos os zeros a esquerda se percam.

A tabela abaixo mostra os campos do MySQL para servir como guia para implementação do banco de dados e sua aplicação.

Você deve identificar qual o tipo de variável que irá armazenar: número, texto, binário, data, lista ou combinação destes. Em seguida estimar o tamanho do campo e se será variável ou fixo. O MySQL costuma preencher campos texto não variáveis com espaços em branco. Em seguida, verificar se permitirá nulo ou não, se é uma chave candidata, primária, estrangeira, índice ou único.

Não há uma regra fixa para saber como os bancos deverão ser implementados, mas tenha sempre em mente que neste caso, mais é melhor. Ou seja, é melhor sobrar espaço do que ter uma informação inserida com pedaços faltando. Já viu alguém nascer no “Rio de Jane” pois o desenvolvedor não colocou o campo com o tamanho correto?!

Observações

O tamanho do campo para tipos numéricos não afeta o intervalo de valores que pode ser armazenado na coluna. Colunas definidas como TINYINT (1) ou TINYINT (20) podem armazenar exatamente, os mesmos valores. Em vez disso, para inteiros, o tamanho determina a largura do campo, para casas decimais, o tamanho é o número total de dígitos que pode ser armazenado.
Muitos dos tipos de dados têm nomes sinônimos: INT e INTEGER, DEC e DECIMAL, etc
O tipo de campo TIMESTAMP é automaticamente definido com a data e hora quando um INSERT ou UPDATE ocorre, mesmo se nenhum valor for especificado para esse campo . Se uma tabela possui múltiplas colunas TIMESTAMP, somente a primeira será atualizada quando um INSERT ou UPDATE é realizado.
MySQL também tem diversas variantes para os tipos de texto que permitem o armazenamento de dados binários. Estes tipos são BINARY, VARBINARY, TINYBLOB, MEDIUMBLOB, e LONGBLOB. Esses tipos são usados para armazenamento de arquivos ou dados criptografados.

Tipos Numéricos
Tipo	Uso		Tamanho
		Atributo	MIN	MAX
TINYINT	Um inteiro muito pequeno	Signed:	-128	127
TINYINT	Um inteiro muito pequeno	Unsigned	0	255
SMALLINT	Um inteiro pequeno	Signed:	–32768	32767
SMALLINT	Um inteiro pequeno	Unsigned	0	65535
MEDIUMINT	Um inteiro de tamanho mediano	Signed:	–8388608	8388607
MEDIUMINT	Um inteiro de tamanho mediano	Unsigned	0	16777215
INT or INTEGER	Um inteiro de tamanho normal	Signed:	–2147483648	2147483647
INT or INTEGER	Um inteiro de tamanho normal	Unsigned	0	4294967295
BIGINT	Um inteiro de temanho grande	Signed:	–9223372036854775808	9223372036854775807
BIGINT	Um inteiro de temanho grande	Unsigned	0	18446744073709551615
FLOAT	Um pequeno número de ponto flutuante (precisão simples)	Signed	–3.402823466E+38	–1.175494351E-38, 0
		Signed	1.175494351E-38	3.402823466E+38
		Não pode ser unsigned	-
		OBS	Se o número de decimais não for especificado ou for <= 24 será de precisão simples
DOUBLE, DOUBLE PRECISION, REAL	Um número de ponto flutuante de tamanho normal (precisão dupla)	Signed	-1.7976931348623157E+308	-2.2250738585072014E-308, 0
		Signed	2.2250738585072014E-308	1.7976931348623157E+308
		Não pode ser unsigned	-
		OBS	Se o número de decimais não for especificado ou for 25 <= Decimals <= 53 será de precisão dupla
DECIMAL, NUMERIC	Um número de ponto flutuante descompactado .	Signed	Se comporta como um campo CHAR: “descompactado” significa que o número é armazenado como uma string, usando um caractere para cada dígito do valor. O ponto decimal e, para números negativos, o sinal ‘-’ não é contado. Se o decimal for 0, os valores não terão ponto decimal ou parte fracionária.	O alcance máximo de valores decimais é o mesmo que para o DOUBLE, mas a faixa atual para um campo DECIMAL dado pode ser limitado pela escolha de comprimento e decimais.
		Não pode ser unsigned	-
		OBS	Se Decimais é deixado de fora ele é definido como 0. Se o comprimento é deixado de fora ele é definido como 10. Note que no MySQL 3,22 o comprimento inclui o sinal eo ponto decimal
Campos de Datas
		Formato	MIN	MAX
DATE	Data		‘1000-01-01’	‘9999-12-31’
DATE	Data	OBS	Formato: ‘YYYY-MM-DD’
DATETIME	Data e horário		‘1000-01-01 00:00:00’	‘9999-12-31 23:59:59’
DATETIME	Data e horário	OBS	Formato: ‘YYYY-MM-DD HH:MM:SS’
TIMESTAMP	Timestamp		‘1970-01-01 00:00:00’	aproximadamente 2037
TIMESTAMP	Timestamp	OBS	Formato: YYYYMMDDHHMMSS, YYMMDDHHMMSS, YYYYMMDD ou YYMMDD, dependendo se M é 14 (ausente), 12, 8 ou 6, podendo ser strings ou números. Este tipo é recomendável para instruções de INSERT ou UPDATE pois é automaticamente marcado com os valores da operação mais recente quando não informado.
TIME	A time		‘-838:59:59’	‘838:59:59’
TIME	A time	OBS	formato: ‘HH:MM:SS’, podem ser strings ou números
YEAR	Anos com 2 ou 4 digitos. O padrão é 4 digitos	4 digitos	1901	2155 e 0000
		2 digitos	1970	2069
		OBS	Formato: YYYY podem ser strings ou números.
Campos Texto
			MIN	MAX
CHAR	String de tamanho fixo. Sempre é completada com espaços a direita até o tamanho definido		1	255 caracteres
CHAR		OBS	Espaços excessivos são removidos quando o valor é trazido.Os valores são ordenados e comparados ignorando caixas altas e baixas de acordo com a codificação padrão, a menos que seja fornecido uma chave binária.
VARCHAR	String de tamanho variável		1	255 caracteres
VARCHAR	String de tamanho variável	OBS	Os valores são ordenados e comparados ignorando caixas altas e baixas de acordo com a codificação padrão, a menos que seja fornecido uma chave binária.Nota: Espaços execessivos são removidos quando o valor é inserido.
TINYTEXT			0	255 (2^8 – 1) caracteres
TEXT			0	65535 (2^16 – 1) caracteres
MEDIUMTEXT			0	16777215 (2^24 – 1) caracteres
LONGTEXT			0	4294967295 (2^32 – 1) caracteres
Dados Binários
TINYBLOB			0	255 (2^8 – 1) caracteres
BLOB			0	65535 (2^16 – 1) caracteres
MEDIUMBLOB			0	16777215 (2^24 – 1) caracteres
LONGBLOB			0	4294967295 (2^32 – 1) caracteres
Listas
			MIN	MAX
ENUM	Enumeração		String que pode conter apenas um valor ou zero	65535 valores distintos.
SET	Lista		String que pode conter zero ou mais valores	64 itens

Tipos de dados para para base de dados SQL

A pergunta que se faz é: - Que tipo de dados são recomendados para criar campos como endereço, e-mail e número de celular/telefone?

A reposta quase sempre pode ser: - Normalmente varchar, mesmo o campo telefone podendo conter apenas números, salvar como texto garante que você não vai perder nenhum zero no inicio do numero.

ou: Para os campos endereço, e-mail e telefone/celular eu recomendo utilizar VARCHAR por ele possuir um tamanho variável e salvar corretamente os dados.

Porque VARCHAR e não CHAR?

O VARCHAR possui um tamanho variável de acordo com a quantidade de dados contido nele.

Exemplo: Vou inserir a palavra "DOUGLAS" que contém 7 caracteres, em uma campo VARCHAR(50), ocupará apenas 7 caracteres no banco, como se fosse um tipo CHAR(7), enquanto se o mesmo dado "DOUGLAS" fosse inserido num campo do tipo CHAR(50), ocuparia 50 caracteres no banco de dados, o que me parece desnecessário.

Nunca utilize tipo numérico para salvar dados como telefone/celular

Vamos supor que você quer salvar o número "0800 800 8000" no banco, o que vai acontecer?

Dependendo do tipo numérico vai ultrapassar o tamanho limite e com isso não vai conseguir salvar no banco os dados.
Você vai perder todos "0" a esquerda do número e com isso você perde a integridade dos dados.

No caso de valores que contém números mais caracteres diversos, é necessário ter cuidado, principalmente se o padrão muda muito. Atender telefones fixos e celulares, como os de São Paulo que tem 9 dígitos, é possível validar na hora de entrar no sistema e uma boa mascara poderá devolver ao formato original, porém a coisa vai ficar complicada se seu sistema tem que suportar também números internacionais e números regionais do Brasil. Na dúvida use VARCHAR.

Não recomendo valores como "numéricos" para CEP e CPF, se for armazenar como numérico marque a coluna como 'ZEROFILL' que ele colocará zeros para preencher os valores iniciais.

A tabela abaixo mostra um exemplo de dados utilizados num cadastro de empresas.

Nome da Coluna	Tipo(Tamanho)
Razão Social	VARCHAR(100)
Nome Fantasia	VARCHAR(100)
CNPJ	VARCHAR(18)
Data de Fundação	DATE
Email	VARCHAR(100)
Website	VARCHAR(100)
Telefone	VARCHAR(14)
Celular	VARCHAR(14)
Nome do Responsável	VARCHAR(100)
Endereço	VARCHAR(100)
Numero	INT(5)
Bairro	VARCHAR(50)
Cidade	VARCHAR(50)
UF	CHAR(2)
CEP	VARCHAR(9)
Descrição	TEXT

Repare que com exceção de UF, sempre se usa VARCHAR, com um tamanho que pode de ser encontrado. Por exemplo, não existe nenhuma cidade nem bairro no Brasil com mais de 50 caracteres.

Utilizando o formato Blob para armazenamento de imagens

No MySQL temos um tipo de dados chamado BLOB, que pode ser utilizado para realizar o armazenamento de dados binários, podendo ser estes arquivos de imagens, pdf, doc, além de poder armazenar vídeos. Um campo do tipo BLOB (Binary Large Objects) é conjunto de dados binários armazenados como uma única entidade em um sistema de gerenciamento de banco de dados. No MySQL existem quatro tipos definidos do BLOB, sendo que a diferença entre eles é o tamanho dos dados que eles podem armazenar as informações:

Tinyblob;
Blob;
Mediumblob;
Longblob.

O menor é o Tinyblob. Este é um campo com armazenamento máximo de 255 caracteres, o que equivale a 8 bits. Já com relação ao Blob, a sua capacidade de armazenamento é em torno dos 16000 caracteres, equivalendo a 16 bits. Em seguida, temos o MediumBlob, que tem uma capacidade de armazenamento superior a 16 milhões de caracteres, o que equivale a mais ou menos 24 bits. Por último, temos o formato LongBlob que pode realizar o armazenamento de mais de 4 bilhões de caracteres, equivalente a 32 bits. Como qualquer recurso de banco de dados, os campos do tipo Blob possuem suas particularidades, podemos destacar que eles não podem ser atribuídos como chaves primárias, exceto o TinyBlob, além do fato de que para estes campos, não podemos utilizar os comandos GROUP e SORT.

Leia mais em: Armazenando Imagens no MySQL http://www.devmedia.com.br/armazenando-imagens-no-mysql/32104#ixzz3sbsOuUZJ

Gerando Script SQL no MySQL Workbench

Para gerar o script SQL, basta exportarmos o modelo diretamente para um formato de Script SQL, que será utilizado no MySQL para a criação do banco de dados.

Figura 3 - Exemplo de modelo de entidade relacionamento.

Para gerar o script, clique em:

Passo 1: File -> Export - Forward Engineer SQL CREATE Script...

Escolha um nome para o arquivo de saída e clique em:

Passo 2: Output SQL Script File: Clique no botão Browse...

Passo 3: Coloque um nome e defina um local para o arquivo e clique em Save

Alternativa: Você pode escolher o nome para o script e clicar em ->Next

Pronto!

Figura 4 - Tela de opções para geração do script SQL.

Arquivo gerado:

SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL';

CREATE SCHEMA IF NOT EXISTS `mydb` DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci ;
USE `mydb` ;

-- -----------------------------------------------------
-- Table `mydb`.`categorias`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `mydb`.`categorias` (
  `idcategorias` INT NOT NULL ,
  `dscategoria` VARCHAR(45) NULL ,
  PRIMARY KEY (`idcategorias`) )
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`produtos`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `mydb`.`produtos` (
  `idprodutos` INT NOT NULL ,
  `dsproduto` VARCHAR(45) NULL ,
  `preco` FLOAT NULL ,
  `qtdade` INT NULL ,
  `foto` LONGBLOB NULL ,
  `categorias_idcategorias` INT NOT NULL ,
  PRIMARY KEY (`idprodutos`) ,
  INDEX `fk_produtos_categorias` (`categorias_idcategorias` ASC) ,
  CONSTRAINT `fk_produtos_categorias`
    FOREIGN KEY (`categorias_idcategorias` )
    REFERENCES `mydb`.`categorias` (`idcategorias` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`clientes`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `mydb`.`clientes` (
  `idclientes` INT NOT NULL ,
  `nome` VARCHAR(100) NOT NULL ,
  `email` VARCHAR(100) NULL ,
  `senha` VARCHAR(100) NULL ,
  PRIMARY KEY (`idclientes`) )
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`pedidos`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `mydb`.`pedidos` (
  `idpedidos` INT NOT NULL ,
  `data` DATE NOT NULL ,
  `status` VARCHAR(45) NOT NULL ,
  `sessao` VARCHAR(45) NOT NULL ,
  `clientes_idclientes` INT NOT NULL ,
  PRIMARY KEY (`idpedidos`) ,
  INDEX `fk_pedidos_clientes1` (`clientes_idclientes` ASC) ,
  CONSTRAINT `fk_pedidos_clientes1`
    FOREIGN KEY (`clientes_idclientes` )
    REFERENCES `mydb`.`clientes` (`idclientes` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`pedidoitens`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `mydb`.`pedidoitens` (
  `idpedidoitens` INT NOT NULL ,
  `qtade` INT NOT NULL ,
  `preco` FLOAT NOT NULL ,
  `total` FLOAT NOT NULL ,
  `pedidos_idpedidos` INT NOT NULL ,
  `produtos_idprodutos` INT NOT NULL ,
  PRIMARY KEY (`idpedidoitens`) ,
  INDEX `fk_pedidoitens_pedidos1` (`pedidos_idpedidos` ASC) ,
  INDEX `fk_pedidoitens_produtos1` (`produtos_idprodutos` ASC) ,
  CONSTRAINT `fk_pedidoitens_pedidos1`
    FOREIGN KEY (`pedidos_idpedidos` )
    REFERENCES `mydb`.`pedidos` (`idpedidos` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_pedidoitens_produtos1`
    FOREIGN KEY (`produtos_idprodutos` )
    REFERENCES `mydb`.`produtos` (`idprodutos` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;



SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;

Gerando Script SQL no DBDesigner4

Para criar um Script SQL para que possamos gerar o banco de dados basta exportarmos o arquivo diretamente para um formato de Script SQL que poderá ser posteriormente utilizado diretamente em um gerenciador de banco de dados que fará a criação do banco de dados. Para isso, devemos ir à opção "File", após isso selecionar "Export" e clicar na opção "SQL Create Script". A Figura 5 mostra como gerar o script.

Figura 5 - Exportando o arquivo SQL para criação do banco de dados.

Após essa etapa, será exibida a tela "Export SQL Script", conforme a Figura 6.

Figura 6 - Tela Export SQL Script exibida na tela.

Nessa tela temos algumas opções como a possibilidade de copiar o script para a área de transferência (opção Copy Script to Clipboard), ou seja, copiamos para a área de transferência e depois colamos em algum editor, ou ainda podemos salvar o script em algum arquivo SQL (que pode ser usado no gerenciador de banco de dados) através do botão "Save Script to File".

Leia mais em: DBDesigner: Modelagem e Implementação de banco de dados http://www.devmedia.com.br/dbdesigner-modelagem-e-implementacao-de-banco-de-dados/30897#ixzz3scFF3P3I

Semana Final

Nesta última semana mostramos um pouco mais da teoria envolvida na modelagem de dados, que é divida em Modelo Conceitual, Modelo Lógico e Modelo Físico, com vídeos e textos explicativos. Apresentamos como deve ser um modelo de entidade e relacionamento (MER), com um exemplo de análise de entidades, falamos sobre atributos, tipos de relacionamento e cardinalidade. Mostramos ainda, os tipos de campos no MySQL com exemplos de tipos mais comuns utilizados e tamanhos. Também falamos do formato BLOB para armazenamento de arquivos de imagens, pdfs e até vídeos. Por fim, mostramos como gerar o Script SQL a partir do modelo lógico, tanto no MySQL Workbench como no DBDesigner. Lembrando que ao gerar o script eu posso transformar o modelo lógico em modelo físico no banco de dados.

Gostaria muito de agradecer a você aluno por ter tido a paciência e a disposição de ver o material da disciplina, como assistir os vídeos, estudar os tutoriais e passo a passos, instalar os programas e fazer os exercícios e atividades obrigatórias.

Gostaria de agradecer ao pessoal de apoio, que entendeu e disponibilizou em tempo recorde todo o material postado no moodle.

Obrigado Tiago e Daniel.

Obrigado a professora Adriana pelo carinho que sempre teve comigo e com os alunos nas aberturas semanais às quintas-feiras.

Obrigado ao professor William pela ajuda na realização da unidade curricular. Acho que podemos melhorar sempre.

Obrigado ao professor Rogério por ter confiado no meu trabalho ajudando na criação da unidade curricular.

Obrigado a todos os outros envolvidos no trabalho. Força sempre!

Foi muito bom estar com todos vocês!

Abraço a todos!

Prof. Douglas A.

Referências

[1] http://help.scibit.com/Mascon/masconMySQL_Field_Types.html

[2] http://dev.mysql.com/doc/refman/5.0/en/data-type-overview.html

<<	<>	<<

PI S8 DSW I DouglasARS: mudanças entre as edições

Edição atual tal como às 08h35min de 27 de novembro de 2015

Índice

Apresentação

Objetivo

Vídeos

Textos

Modelagem de dados

Modelo conceitual

Modelo lógico

Modelo físico

Conclusão

Modelo de Entidade e Relacionamento (MER)