Aplicativos em PHP/Apêndices/Análise e Projeto
Análise de Sistemas na Wikipedia
A atividade de análise tem como finalidade realizar estudos de processos afim de encontrar o melhor e mais racional caminho para que a informação possa ser processada. O analista de sistema estuda os diversos sistemas existentes entre hardwares (equipamento), softwares (programas) e o usuário final, seus comportamentos e aplicações, desenvolvendo a partir de então soluções que serão padronizadas e transcritas da forma que o computador possa executar. Gerando o que se chama de softwares (programas), que são executados em hardwares (equipamentos) operados por usuários, indivíduos, preparados e treinados em procedimentos operacionais padronizados, dotados de conhecimentos do software e hardware para seu trabalho. A partir de então a análise de sistemas é uma profissão, cujas responsabilidades concentram-se na programação e na administração de sistemas computacionais. Cabe a este profissional parte da organização, implantação e manutenção de aplicativos e redes de computadores. Como é uma ênfase, o foco e o núcleo de trabalho está voltado para Administração, levando em conta a área tecnológica em que irá auxiliar.
Fonte: http://pt.wikipedia.org
Projeto na Wikipedia
Segundo o Project Management Institute, projeto é um esforço temporário empreendido para criar um produto ou serviço único. Desta forma, um projeto tem início e fim definidos e resulta em um produto ou serviço de alguma forma diferente de todos os outros anteriormente produzidos.
Seu resultado pode ser:
Um produto ou objeto produzido, quantificável e que pode ser um item final ou um item componente
Uma capacidade de realizar um serviço, como funções de negócios que dão suporte à produção ou à distribuição
Um resultado, como resultados finais ou documentos. Por exemplo, um projeto de pesquisa desenvolve um conhecimento que pode ser usado para determinar se uma tendência está presente ou não ou se um novo processo irá beneficiar a sociedade.
A singularidade é uma característica importante das entregas do projeto. Por exemplo, muitos milhares de prédios de escritórios foram construídos, mas cada prédio em particular é único: tem proprietário diferente, projeto diferente, local diferente, construtora diferente, etc. A presença de elementos repetitivos não muda a singularidade fundamental do trabalho do projeto.
Antes do projeto, é comum ainda o trabalhador fazer a preparação de um Anteprojeto, que é o estudo preparatório do projeto.
Nos contextos de software, projeto é usado com o sentido do ato de projetar, de conceber antecipadamente. Neste caso, costuma-se também empregar a palavra design.
Fonte: http://pt.wikipedia.org
Técnicas de levantamento de dados - Parte 1: Entrevistas
Em dois bons artigos do Bernardo Pina no seu Blog Produzindo.net:
http://www.produzindo.net/tecnicas-de-levantamento-de-dados-parte-1-entrevistas/
Técnicas de levantamento de dados - Parte 2: Questionários
http://www.produzindo.net/tecnicas-de-levantamento-de-dados-parte-2-questionarios/
Gerenciamento de Projetos: Os 10 mandamentos
http://www.efetividade.net/2007/09/20/gerenciamento-de-projetos-os-10-mandamentos/
Análise e Projeto
1.Introdução
2.Objetivos e Justificativa
Devem ser definidos o problema existente, o propósito do site (objetivos), por que ele é importante ou necessário (justificativa), para quem ele será útil (usuários), qual o escopo do site (intranet, internet ou extranet) e outras informações que você julgar convenientes e necessárias.
3.Descrição dos requisitos
Requisitos de conteúdo - quais informações o site oferece
Requisitos funcionais - quais serviços são oferecidos aos usuários
Requisitos de desenvolvimento - quais recursos materiais e humanos foram utilizados
Requisitos operacionais - quais equipamentos de hardware e quais sistemas de software serão necessário para o web site funcionar. Como será feita a conexão com a internet.
4.Design - descrição gráfica acompanhada de um texto descrevendo:
Estrutura organizacional do site - O design da organização envolve a estruturação das diversas páginas que formarão o site, da interligação entre elas.
Aspectos estéticos: Esquema de Layout do banco de dados e dos scripts, estilos de fontes, uso das cores, etc., justificando a sua escolha
5.Anexos: descrição dos arquivos de HTML, CSS, JavaScript, PHP, etc, que forem utilizados.
Adaptado do original em - http://www.dimap.ufrn.br/~jair/piws/exercicios2004.html
Faça as perguntas:
- O que iremos desenvolver?
- Como desenvolver?
- Já existe aplicativo similar?
- Se existe, podemos reutilizar algo do mesmo?
Algoritmo e Lógica
Algoritmo na Wikipedia
Um algoritmo é uma sequência finita e não ambígua de instruções para solucionar um problema. Mais especificamente, em matemática, constitui o conjunto de processos (e símbolos que os representam) para efetuar um cálculo. Algoritmos podem ser implementados por programas de computadores. A palavra algoritmo tem origem no sobrenome, Al-Khwarizmi, do matemático persa do século IX, Mohamed ben Musa, cujas obras foram traduzidas no ocidente cristão no século XII, tendo uma delas recebido o nome "Algorithmi de numero indorum", sobre os algoritmos usando o sistema de numeração decimal (indiano). Outros autores, contudo, defendem a origem da palavra em Al-goreten (raiz - conceito que se pode aplicar aos cálculos).
O conceito de algoritmo é frequentemente ilustrado pelo exemplo de uma receita, embora muitos algoritmos sejam mais complexos. Eles podem repetir passos (fazer iterações) ou necessitar de decisões (tais como comparações ou lógica) até que a tarefa seja completada. Um algoritmo corretamente executado não irá resolver um problema se o algoritmo estiver incorreto ou não for apropriado ao problema.
Um algoritmo não representa, necessariamente, um programa de computador, e sim os passos necessários para realizar uma tarefa. Sua implementação pode ser feita por um computador, por outro tipo de autômato ou mesmo por um ser humano.
Diferentes algoritmos podem realizar a mesma tarefa usando um conjunto diferenciado de instruções em mais ou menos tempo, espaço ou esforço do que outros. Por exemplo, um algoritmo para se vestir pode especificar que você vista primeiro as meias e os sapatos antes de vestir a calça enquanto outro algoritmo especifica que você deve primeiro vestir a calça e depois as meias e os sapatos. Fica claro que o primeiro algoritmo é mais difícil de executar que o segundo.
Fonte: http://pt.wikipedia.org
Lógica e computadores
A Lógica é extensivamente usada em áreas como Inteligência Artificial, e Ciência da computação.
Nas décadas de 50 e 60, pesquisadores previram que quando o conhecimento humano pudesse ser expresso usando lógica com notação matemática, supunham que seria possível criar uma máquina com a capacidade de pensar, ou seja, inteligência artificial. Isto se mostrou mais difícil que o esperado em função da complexidade do raciocínio humano. programação lógica é uma tentativa de fazer computadores usarem raciocínio lógico e a linguagem de programação Prolog é comumente utilizada para isto.
Na lógica simbólica e lógica matemática, demonstrações feitas por humanos podem ser auxiliadas por computador. Usando demonstração automática de teoremas os computadores podem achar e checar demonstrações, assim como trabalhar com demonstrações muito extensas.
Na ciência da computação, a álgebra booleana é a base do projeto de hardware.
Projeto de Bancos de Dados
O que me levou a compilar este tutorial foi a grande carência de material nesta área, especialmente em português. Se aplicam a qualquer SGBD.
Introdução Teórica
O projeto do banco de dados e também os testes são muito importantes para a eficiência e consistência das informações e do aplicativo. É muito importante gastar algum tempo nesta etapa, pois depois de algum tempo de implantado fica muito trabalhoso alterar estruturas de bancos e aplicativos.
Projetos de banco de dados ineficazes geram consultas que retornam dados inesperados, relatórios que retornam valores sem sentido, etc. Um banco de dados bem projetado fornece um acesso conveniente às informações desejadas e resultados mais rápidos e precisos.
Lembrando:
- SGBDR (Sistema Gerenciador de Bancos de Dados Relacional) – PostgreSQL
- Software de administração de banco de dados para o PostgreSQL – PGAdmin
Informações de bancos de dados relacionais são armazenadas em tabelas ou entidades no Modelo ER (Entidade-Relacionamento).
Dicas sobre Campos
Não armazenar resultado de cálculos ou dados derivados de outros
Armazenar todas as informações (campos) separadamente. Cuidado com campos que contém duas ou mais informações.
Selecionando o Campo para a Chave Primária
A chave primária é o campo ou campos que identificam de forma exclusiva cada registro.
Não são permitidos valores nulos nem duplicados na chave.
Caso a tabela não tenha um campo que a identifique, pode-se usar um campo que numere os registros seqüencialmente.
Dica de Desempenho: O tamanho da chave primária afeta o desempenho das operações, portanto usar o menor tamanho que possa acomodar os dados do campo.
Exemplo
Tabela – Clientes Campo – Nome (atributo) Chave Primária (Primary Key) – CPF
Todos os campos correspondentes a um único CPF juntamente com seus valores formam um Registro ou Linha (Row)
A correta determinação das tabelas, bem como dos campos é algo primordial no sucesso do projeto do banco de dados.
Chave Primária
Obriga que todos os registros terão o campo correspondente à chave primária exclusivo (único - unique). Num cadastro de clientes, todos os clientes cadastrados terão um campo CPF exclusivo. Caso se tente inserir dois clientes com o mesmo CPF o banco não permitirá e emitirá uma mensagem de erro acusando tentativa de violação da chave primária.
Exemplos de Campos indicados para chave primária:
CPF CNPJ Matrícula de aluno Matrícula de funcionário
Uma chave primária pode ser formada por mais de um campo, quando um único campo não é capaz de caracterizar a tabela.
Cada tabela somente pode conter uma única chave primária.
Relacionamentos – Um banco de dados é formado por várias tabelas. Idealmente essas tabelas devem ser relacionadas entre si para facilitar a troca de informações e garantir a integridade. Para relacionar tabelas usamos chaves existentes nas mesmas.
Tipos de Relacionamentos
Um para um Um para vários Vários para vários
Relacionamento Um para Um
Aquele onde os campos que fazem o relacionamento são chaves primárias. Cada registro de uma tabela se relaciona com apenas um registro da outra tabela.
Este relacionamento não é muito comum.
Exemplo: CorrentistaBanco - Conjuge
Relacionamento Um para Vários
Aquele onde uma tabela tem um campo chave primária (PK) que se relaciona com outra tabela através de um campo chave estrangeira (FK) . É o tipo de relacionamento mais utilizado.
Exemplos:
Clientes – Pedidos Produtos – Itens Categorias – Itens Fornecedores – Produtos NotaFiscal - Produtos
Veja que cada registro da esquerda se relaciona com vários registros da direita.
Importante:
O tipo de dados dos campos do relacionamento deve ser igual, assim como o tamanho dos campos e formatos
Chave primária – Chave estrangeira (um – vários)
Relacionamento Vários para Vários
Este tipo de relacionamento não dá para ser implementado no modelo relacional, portanto sempre que nos deparamos com um deles devemos dividir em dois relacionamentos um para vários (criando uma terceira tabela, que armazenará o lado vários dos relacionamentos).
Exemplo:
Pedidos – Produtos (1 --- N e N --- 1)
Cada pedido pode conter vários produtos, assim como cada produto pode estar em vários pedidos. A saída é criar uma tabela que contenha os itens do pedido.
Pedidos – Pedidos_Itens – Produtos
Pedidos 1 - N Pedidos_Itens N - 1 Produtos
Integridade Referencial
Ela garante a integridade dos dados nas tabelas relacionadas. Um bom exemplo é quando o banco impede que se cadastre um pedido para um cliente inexistente, ou impede que se remova um cliente que tem pedidos em seu nome.
Também se pode criar o banco de forma que quando atualizamos ou excluímos o CPF de um cliente ele seja atualizado ou excluído em todos os seus pedidos.
Normalização de Tabelas
Normalizar tabelas e bancos tem o objetivo de tornar o banco mais eficiente, impondo integridade aos dados.
Uma regra muito importante ao criar tabelas é atentar para que cada tabela contenha informações sobre um único assunto, de um único tipo.
1a Forma Normal
Os campos não devem conter grupos de campos que se repetem nos registros.
Exemplo:
Alunos: matricula, nome, data_nasc, série, pai, mae
Se a escola tem vários filhos de um mesmo casal haverá repetição do nome dos pais. Estão para atender à primeira regra, criamos outra tabela com os nomes dos pais e a matrícula do aluno.
2ª Forma Normal
- Quando a chave primária é composta por mais de um campo. - Devemos observar se todos os campos que não fazem parte da chave dependem de todos os campos que fazem parte da chave.
Caso algum campo dependa somente de parte da chave, então devemos colocar este campo em outra tabela.
Exemplo:
TabelaAlunos
Chave (matricula, codigo_curso)
avaliacao
descricao_curso
Neste caso o campo descricao_curso depende apenas do codigo_curso, ou seja, tendo o código do curso conseguimos sua descrição. Então esta tabela não está na 2ª Forma Normal.
Solução:
Dividir a tabela em duas (alunos e cursos):
TabelaAlunos
Chave (matricula, codigo_curso)
avaliacao
TabelaCursos
codigo_curso descricao_curso
3ª Forma Normal
Quando um campo não é dependente diretamente da chave primária ou de parte dela, mas de outro campo da tabela que não pertence à chave primária. Quando isso ocorre esta tabela não está na terceira forma normal e a solução é dividir a tabela.
Lembrando: Engenharia Reversa (parte de um banco existente ou de um script SQL e gera o modelo).
Projeto
Fases do Projeto do Banco de Dados
Modelo Conceitual
Modelo Lógico
Modelo Físico (faz parte apenas da implementação)
Observação.: Trataremos apenas de novos projetos.
Modelo Conceitual – Define apenas quais os dados que aparecerão no banco de dados, sem se importar com a implementação do banco. Para essa fase o que mais se utiliza é o DER (Diagrama Entidade-Relacionamento).
Modelo Lógico – Define quais as tabelas e os campos que formarão as tabelas, como também os campos-chave, mas ainda não se preocupa com detalhes como o tipo de dados dos campos, tamanho, etc.
Etapas na Estruturação e Projeto de um Banco de Dados
Problemas a serem solucionados com o banco de dados
Determinar as tabelas necessárias (cada uma com um único assunto exclusivo)
Determinar os campos de cada tabela
Criar um DER
Verificar a estimativa do crescimento do banco e preparar-se para isso
Investigar como são armazenadas as informações atualmente e recolher a maior quantidade de informações para o projeto
Adotar um modelo e justificá-lo
(Os itens acima fazem parte do Modelo Conceitual e abaixo do Lógico)
Determinar a chave primária de cada tabela. Pode haver tabela sem chave primária.
Determinar os relacionamentos e seus tipos
Obs.: Somente quando da implementação (modelo físico) serão tratados os detalhes internos de armazenamento. O modelo físico é a tradução do modelo lógico para a linguagem do SGBDR adotado.
Projeto Exemplo
Vamos elaborar um exemplo de projeto de banco de dados que será um controle de funcionários.
Controle de Funcionários
Modelo Conceitual
Problemas a serem solucionados com o banco de dados
Atualmente os funcionários são cadastrados em fichas de papel guardadas em pastas. Isso acarreta dificuldade no resgate de informações e fragilidade das mesmas.
O objetivo do banco de dados será armazenar as informações sobre os funcionários, possibilitando consultas ágeis que retornem as informações de maneira rápida e prática.
Determinar as tabelas necessárias (cada uma com um único assunto exclusivo)
Utilizaremos apenas a tabela funcionarios, contendo todos os dados dos funcionários.
Determinar os campos da tabela
Os campos serão: cpf, nome, email, endereco, cep, cidade, estado, fone, celular, conjuge, filhos.
Criar um DER (uma ótima ferramenta é o plugin para Eclipse Azzurri Clay).
funcionarios cpf nome ...
Hardware indicado para abrigar o servidor de banco de dados
O hardware mais adequado deve ter um disco rígido rápido, boa quantidade de memória RAM, uma boa placa-mãe e um bom processador. As especificações dependem de cada caso.
Software indicado como o servidor dos bancos
Como SGBDR a indicação vai para o PostgreSQL,por ser robusto, estável, bom desempenho, boa documentação, grande comunidade através da Internet e Licença free e open-source para todos os usos.
Como sistema operacional para o servidor a indicação vai para o Linux Debian.
Como sistema operacional para os clientes a indicação vai para o Linux Ubuntu.
Verificar a estimativa do crescimento do banco e preparar-se para isso
A empresa é pequena mas tem perspectiva de crescimento a médio e longo prazo...
Adotar um modelo e justificá-lo
O modelo adotado foi o MER (Modelo Entidade-Relacionamento), por atender às necessidades do cliente e ser o modelo padrão de mercado atualmente.
Modelo Lógico
Teremos apenas uma tabela, funcionarios, cuja chave primária é o campo CPF.
Aplicar as 3 formas normais para testar a coerência das tabelas.
Primeira - Os campos não devem conter grupos de campos que se repetem nos registros.
Cada funcionário terá todos os campos diferentes, exceto alguns campos isolados, como cep, cidade, mas não temos grupos de campos que se repetem.
Sugestão: Ter cidade, cep e estado em tabelas diferentes e relacionadas, deixando em funcionários apenas combos onde seriam selecionados.
Mas tanto o campo conjuge quanto o filhos devem ir para tabelas separadas, já que cônjuge pode armazenar várias informações e filhos também.
Então teremos as tabelas:
funcionarios, conjuges e filhos, de acordo com o DER abaixo.
Utilizando o DBDesigner, o DER acima gerou o script abaixo:
CREATE TABLE funcionarios (
cpf VARCHAR NOT NULL,
nome VARCHAR NULL,
endereco VARCHAR NULL,
cep VARCHAR NULL,
cidade VARCHAR NULL,
estado VARCHAR NULL,
cod_conjuge VARCHAR NULL,
cod_filhos VARCHAR NULL,
PRIMARY KEY(cpf)
);
CREATE TABLE func_filhos (
codigo INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
funcionarios_cpf VARCHAR NOT NULL,
nome VARCHAR NULL,
cpf_funcionario VARCHAR NULL,
data_nascimento DATE NULL,
PRIMARY KEY(codigo),
FOREIGN KEY(funcionarios_cpf)
REFERENCES funcionarios(cpf)
ON DELETE NO ACTION
ON UPDATE NO ACTION
);
CREATE TABLE func_conjuge (
cpf_funcionario VARCHAR NOT NULL AUTO_INCREMENT,
funcionarios_cpf VARCHAR NOT NULL,
nome INTEGER NULL,
data_nascimento DATE NULL,
PRIMARY KEY(cpf_funcionario),
FOREIGN KEY(funcionarios_cpf)
REFERENCES funcionarios(cpf)
ON DELETE NO ACTION
ON UPDATE NO ACTION
);
funcionarios 1 – 1 conjuge
funcionarios 1 – N filhos
Tutorial sobre uso do DBDesigner com PostgreSQL: http://wwwpostgresql.org.br
Segunda Forma Normal – Quando a chave primária é composta por mais de um campo.
Não é o caso, pois CPF é suficiente para representar cada funcionário.
Terceira Forma Normal- Quando um campo não é dependente diretamente da chave primária ou de parte dela, mas de outro campo da tabela que não pertence à chave primária. Não é o caso.
Referências
- O Modelo Relacional de Dados (em cinco artigos, de Júlio Battisti ) http://www.imasters.com.br/artigo.php?cn=2419&cc=149
- Conceitos Fundamentais de Banco de Dados (de Ricardo Rezende) http://www.sqlmagazine.com.br/Colunistas/RicardoRezende/02_ConceitosBD.asp