PI S5 DSW II DouglasARS

Apresentação

Olá Estudante,

Nessa quinta semana vamos levantar alguns questionamentos relatados a partir da correção da AO1. Vamos apresentar novas formas de desenvolvimento. Precisamos preparar o banco de dados para começarmos a desenvolver as telas e fazer o acesso ao banco de dados. Assistam as vídeo aulas e repitam os desenvolvimento já utilizando o sistema que vocês escolheram...

Bons estudos!

Prof. Douglas A.

Objetivo

1. Apresentar as considerações sobre a modelagem do banco de dados.
2. Mostrar detalhes da programação de formulários quanto a consulta de dados.

Segurança

Qualquer sistema requer o mínimo de segurança. Outras unidades curriculares vão abordar mais particularmente a questão de segurança. Nas semanas anteriores foram apresentados vídeos mostrando como fazer telas de login e senha de usuário, para acessar o sistema. Ficaram algumas dúvidas e com a ajuda do nosso colega Kleber (Joinville) podemos ter uma ideia um pouco mais avançada para o tema e, ao mesmo tempo, resolvemos alguns problemas de acesso, acrescentamos um pouco mais de segurança ao nosso sistema. Abaixo ele explica o que fazer:

por KLEBER PEREIRA DE ALMEIDA - Sunday, 6 de March de 2016, 21:25

Caso alguém esteja enfrentando problemas em realizar o login utilizando os scripts disponibilizados pelo professor (login.php, seguranca.php e valida.php), vão as dicas... No arquivo "seguranca.php" altere os dados do servidor, usuário, senha e banco de acordo com seu projeto, eu alterei meu case sensitive para true (opcional). Verifique se seu projeto já não possui uma tabela "usuarios", provavelmente sim, recomendo alterar o script de seu projeto no Workbench de maneira a tabela "usuarios" ficar igual a do script fornecido pelo professor. Depois basta inserir os dados na tabela, afinal, precisamos de no mínimo um usuário cadastrado para autenticarmos. É preciso também um mínimo de segurança nas informações prestadas pelo usuário, então insira a senha utilizando criptografia/ hash ex.:

INSERT INTO usuarios (nome, usuario, senha)
VALUES ('Kleber Pereira de Almeida', 'kleber', MD5('teste');

Não esqueça que a comparação da senha também deverá ser criptografada, ou seja na linha 9 do arquivo "valida.php" altere para:

$senha = isset($_POST['senha']) ? MD5($_POST['senha']) : '';

Espero ter ajudado, caso alguém tenha encontrado estas pequenas barreiras no caminho.

Obrigado Kleber.

Aluguel de Carros

Consideração 1

Uma das tabelas do sistema Aluguel de Carros e a Costumer que traduzindo é Cliente. Abaixo, segue um exemplo de modelagem complicada por vários fatores que relaciono abaixo. Mostro também um exemplo de como poderia ser modelada essa mesma tabela.

CREATE TABLE IF NOT EXISTS `mydb`.`Cliente` (
`idCliente` INT NOT NULL,
`Nome do Cliente` VARCHAR(45) NULL,
`Descrição do Cliente` VARCHAR(45) NULL,
`Sexo` VARCHAR(45) NULL,
`endereço de e-mail` VARCHAR(45) NULL,
`Número telefone` VARCHAR(45) NULL,
`Endereço Residencial` VARCHAR(45) NULL,
`Endereço Comercial` VARCHAR(45) NULL,
`Endereço Corespondência` VARCHAR(45) NULL,
`Cidade` VARCHAR(45) NULL,
`Estado` VARCHAR(45) NULL,
`País` VARCHAR(45) NULL,
PRIMARY KEY (`idCliente`))

Primeira observação:

Nome (espaço) do (espaço) Cliente

Embora o MySQL deixe criar, isto pode causar grandes programas no desenvolvimento e erros de codificação . Sugiro que vocês revejam os modelos no Workbench ou no DBDesigner com os nomes de campos sem espaço, sem cedilha, sem acentos, sem caracteres especiais como $, &, %.

Segunda observação:

Também parece que não houve muita preocupação com os tamanhos dos campos. Está tudo com 45 caracteres. Acontece que na maioria dos casos é suficiente para abrigar um nome de pessoa ou mesmo um endereço, mas sempre deve-se pensar no pior caso, pra não precisa ficar dando manutenção no sistema/banco de dados e alterando o tamanho do campo na respectiva tabela no banco de dados. Outro problema, se as reservas vão ser em hotéis do Brasil, tem que ver se o tamanho de 45 para o estado do cliente não é grande demais. Não que isso vá alterar qualquer coisa no sistema, mas também me parece, que está exagerado. Mas isso vai de cada um desenvolvedor/programador.

Exemplos para o campo "Nome de Cliente":

nome_do_cliente varchar(100) not null,

nm_cliente varchar(100) not null,

nomeCliente varchar(100) not null,

nome varchar(100) not null,

Deve ser not null porque necessariamente um cliente deve ter um nome.

Não é recomendado que se use acentuação. Outros servidores de outros países podem não estar preparados para a codificação com acentuação e outros caracteres especiais, entre outros problemas, então, por exemplo, mostro como poderia ser criada essa mesma tabela Cliente a partir do modelo da tabela Costumer do modelo conceitual (inicial) do sistema Aluguel de Carros:

CREATE TABLE IF NOT EXISTS `mydb`.`Cliente` (
`id_cliente` INT NOT NULL,
`nome_cliente` VARCHAR(100) NOT NULL,
`obs_cliente` VARCHAR(100) NULL,
`sexo` CHAR(1) NULL,
`email` VARCHAR(100) NULL,
`telefone` VARCHAR(20) NULL,
`endereco` VARCHAR(100) NULL,
`cidade` VARCHAR(50) NULL,
`uf` VARCHAR(2) NULL,
`pais` VARCHAR(50) NULL,
PRIMARY KEY (`id_cliente`))

Embora o modelo original tenha aberto espaço de 3 linhas para o endereço, trata-se do mesmo endereço. Se fosse endereços diferentes, teria que ter, necessariamente: 3 cidades, 3 estados e até 3 países.

Prof. Douglas A.

Consideração 2

O campo engine_size da tabela Vehicle (no modelo conceitual) teve seu campo traduzido para tamanho_motor da tabela Veiculo. Para quem não questionou tal tradução, bem como outras, este campo poderia ser potencia_motor ou mesmo cilindrada. Tomem cuidado com os tamanhos de campos e vejam se todos os campos vão receber "aqueles" tipos de dados que vocês estão imaginando. Claro, que muita coisa vai ser percebida, quando começarem a programar os formulários de entrada e consultas, nos primeiros testes, vocês vão perceber que um ou outro campo precise ser de tamanho ou tipo diferente. Ou mesmo o nome diferente. Daí se faz a manutenção no banco de dados e não podendo esquecer de atualizar o modelo.

Prof. Douglas A.

Reservas de Hotéis

Esse sistema é relativamente maior, com bastante coisa pra programar, mas vale a pena as equipes tentarem ir até o final.

Numa das correções, eu observei que a tabela original Room_Rate_Periods (tarifa_quarto_periodo) ficou com informações que parecem campos, mas na verdade são só exemplos do que deve conter o campo descricao_tarifa_periodo. Portanto, no novo modelo relacional e no físico (banco de dados) esses "campos" da tabela não devem ser criados.

CREATE TABLE IF NOT EXISTS `Reseva_Hotel_Jorge`.`tarifa_quarto_periodo` (
`idtarifa_quarto_periodo` INT(11) NOT NULL,
`codigo_tarifa__periodo` INT(11) NOT NULL,
`descricao_tarifa_periodo` VARCHAR(255) NOT NULL,
`ex Jan ate Mar` INT(11) NOT NULL,
`ex Set ate Dez` INT(11) NOT NULL,
`tarifa_periodo_tipos_quarto_idtipos_quarto` INT(11) NOT NULL,
PRIMARY KEY (`idtarifa_quarto_periodo`))

Os campos abaixo são só exemplo do que o usuário do sistema tem escrever nesse campo:

`ex Jan ate Mar` INT(11) NOT NULL,
`ex Set ate Dez` INT(11) NOT NULL,

Nos dois exemplos, o código da tarifa é válida entre Janeiro a Março ou Setembro a Dezembro.

Aqui no Brasil podia ter haver com o período de férias de verão, de inverno ou alta temporada e baixa temporada.

Até mais.

Prof. Douglas A.

Organização da Semana 6

Nesta quinta semana ...

Prof. Douglas A.

Referências

[1]

[2]

---

<<	<>	>>