tudo são dados - php conference 2008
Post on 25-May-2015
1.306 Views
Preview:
DESCRIPTION
TRANSCRIPT
TUDO SÃO DADOS!
DIEGO THOMAZ FLÔRESwww.ecrayon.com.br
PHP Conference 2008
TUDO SÃO DADOSPHP Conference 2008
DIEGO THOMAZ FLÔRES
Analista e programador PHP há 6 anos, já desenvolveu projetos de médio e grande porte para clientes como o Ministério do Turismo, EMBRATUR, Fundação Getúlio Vargas - RJ, GMagazine, Telefonica e Agência Click.
Atua como Gerente de Projetos na Bolsoni Tecnologia & Turismo, desenvolvendo e coordenando os projetos Brasil.com.br e Boletim de Ocupação Hoteleira (EMBRATUR/FGV-RJ). É aluno do último ano do curso superior em Análise de Bancos de Dados no IBTA – São Paulo/SP.
Além disso, é responsável pela ECRAYON Tecnologia Criativa, estúdio de desenvolvimento de sistemas web-based.
TUDO SÃO DADOSPHP Conference 2008
ALGUNS CASES
TUDO SÃO DADOSPHP Conference 2008
AGENDA
Especificação de Requisitos
• Conceituação• Técnicas para captura de requisitos
Modelagem de Dados
• Conceituação• Projetando o Banco de dados• Normalização
TUDO SÃO DADOSPHP Conference 2008
“O modo mais provável do mundo ser destruído, como concorda a maioria dos especialistas, é através de um acidente. É ai que nós entramos. Somos profissionais de computação. Nós causamos acidentes.”
Nathaniel Borestein
TUDO SÃO DADOSPHP Conference 2008
Estudos mostram que 50% das falhas no setor industrial alemão são causadas por erros em software.
1977: Média de 7-20 defeitos por 1000 linhas de código1994: Média de 0,2-0,05 defeitos por 1000 linhas de código
A tolerância de um nível de defeito de 0,1% significa:
por ano: 20.000 medicamentos defeituosos300 falhas em marcapassos
por semana: 500 erros em operações médicas
por dia: 16.000 cartas perdidas nos correios18 quedas de aviões
por hora: 22.000 cheques descontados incorretamente
TUDO SÃO DADOSPHP Conference 2008
AS SETE QUESTÕES FUNDAMENTAIS PARA O PLANEJAMENTO DE SOFTWARE
1. Por que o sistema vai ser construído?
2. O que deve ser feito?
3. Como vai ser feito?
4. Quando vai ser feito?
5. Quem vai fazer? E quem são os responsáveis?
6. Onde se aplicam essas responsabilidades?
7. Quanto vai custar?
TUDO SÃO DADOSPHP Conference 2008
FASES DO PLANEJAMENTO DE SOFTWARE
Definição
Desenvolvimento
Manutenção
Análise do Sistema
Planejamento do projeto
Análise de Requisitos
Projeto de Software
Codificação
Realização de Testes
Correção
Adaptação
Expansão
TUDO SÃO DADOSPHP Conference 2008
FASE 1: DEFINIÇÃO ou ESPECIFICAÇÃO
Por quê?Identificação do problemaAnálise da situação atual
O quê?Definição conceitual de soluções
Como?Definição do escopo globalPlanejamento do projeto de softwareAnálise de riscos
Quando?Refinamento do escopoCronograma geralCronograma modular
Quem?Alocação de recursos
Onde?Definição de responsabilidades;Definição de ambientes de desenvolvimento, homologação e produção.
Quanto?Estimativa de custosCronograma específico
TUDO SÃO DADOSPHP Conference 2008
FASE 2: DESENVOLVIMENTO
Projeto de Software
Traduz os requisitos do software num conjunto de representações que descrevem a estrutura de dados, a arquitetura do software, os procedimentos algorítmicos e as características de interface.
Codificação
As representações do projeto devem ser convertidas numa linguagem artificial que resulte em instruções que possam ser executadas pelo computador.
Realização de Testes
Logo que o software é implementado numa forma executável por máquina, ele deve ser testado para que se possa descobrir defeitos de função, lógica e implementação.
TUDO SÃO DADOSPHP Conference 2008
FASE 3: MANUTENÇÃO
Correção
Mesmo com as melhores atividades de garantia de qualidade de software, é provável que o cliente descubra defeitos no software
Adaptação
Com o passar do tempo, o ambiente original para o qual o software foi desenvolvido provavelmente mudará. A manutenção adaptativa muda o software para acomodar mudanças em seu ambiente.
Expansão
À medida que o software é usado, o usuário reconhecerá funções adicionais que oferecerão benefícios.
TUDO SÃO DADOSPHP Conference 2008
MODELOS DE PROCESSO DE SOFTWARE
Consiste em uma série de atividades que garantem, técnica e administrativamente que o software pode ser desenvolvido de maneira organizada, disciplinada e previsível.
Um modelo de processo procura descrever formalmente e de maneira organizada todas as atividades que devem ser seguidas para a obtenção segura de um produto de software. É importante escolher um modelo apropriado às metas da organização e saber o grau em que esse modelo será implementado.
BENEFÍCIOS
• Estabelece uma linguagem comum;
• Constrói um conjunto de processos e procedimentos desenvolvidos com sugestões de uma ampla participação da comunidade de software;
• Oferece uma estrutura para se priorizar as ações.
RISCOS
• Não são suficientemente abrangentes;
• É necessário bom senso para se utilizar modelos corretamente e com visão.
TUDO SÃO DADOSPHP Conference 2008
MODELOS DE PROCESSOS DE SOFTWARE: LINEAR ou CASCATA
Engenharia de Engenharia de SistemasSistemas
Engenharia de Engenharia de SistemasSistemas
Análise de Análise de Requisitos Requisitos
Análise de Análise de Requisitos Requisitos
Projeto Projeto Projeto Projeto
Codificação Codificação Codificação Codificação
Testes Testes Testes Testes
Manutenção Manutenção Manutenção Manutenção
TUDO SÃO DADOSPHP Conference 2008
PROBLEMAS NA IMPLEMENTAÇÃO LINEAR ou CASCATA
Dificuldade em prever todos os detalhes de funcionamento e comunicação dos módulos logo no início do projeto;
O prazo de entrega do produto final é sempre maior, uma vez que a etapa seguinte só inicia quando a anterior estiver completamente finalizada;
Os custos do projeto aumentam devido à alocação desnecessária e ociosa de recursos, que ficam à espera das fases anteriores serem finalizadas para iniciarem suas atividades.
TUDO SÃO DADOSPHP Conference 2008
MODELOS DE PROCESSOS DE SOFTWARE: PROTOTIPAÇÃO
construa/reviseo protótipo
construa/reviseo protótipo
teste doprotótipo pelo
cliente
teste doprotótipo pelo
cliente
ouça o clienteouça o cliente
TUDO SÃO DADOSPHP Conference 2008
PROBLEMAS NA IMPLEMENTAÇÃO POR PROTOTIPAÇÃO
Cliente cria grande espectativa em cima do prótipo e na maioria das vezes não enxerga o mesmo como um modelo híbrido do produto final;
Desenvolvedor freqüentemente faz uma adaptação do modelo híbrido para o modelo final do produto, comprometendo a qualidade do código.
TUDO SÃO DADOSPHP Conference 2008
MODELOS DE PROCESSOS DE SOFTWARE: ESPIRAL
É um modelo iterativo, que integra as etapas características do desenvolvimento linear com a familiarização do cliente ao produto final, típicas da prototipação.
Nas primeiras iterações a versão incremental pode ser um modelo em papel ou um protótipo; nas iterações mais adiantadas são produzidas versões incrementais mais completas e melhoradas.
Dinamiza e facilita possíveis correções ou alterações de escopo a cada iteração, permitindo melhor execução e implementação do produto final sem comprometer o cronograma geral.
PlanejamentoAnálise de Risco
Engenharia
Construção e ReleaseAvaliação do Cliente
Adaptações
TUDO SÃO DADOSPHP Conference 2008
TÉCNICAS PARA LEVANTAMENTO DE REQUISITOS
Entrevistas
É a técnica mais utilizada para captura de requisitos. A característica básica da entrevista é o diálogo entre o entrevistador e um entrevistado.
Questionários
Série de perguntas escritas para obter informações de indivíduos, usados quando há um grande número de pessoas de quem as informações e opiniões são necessárias. Também é muito utilizado para sistemas a serem implantados fora do cliente ou para sistemas com usuários espalhados em diversos locais.
JAD – Joint Application Design
Workshops de imersão, realizado em três etapas, onde reunem-se ao mesmo tempo usuários gerais, especializados, desenvolvedores e representantes do cliente.
TUDO SÃO DADOSPHP Conference 2008
ENTREVISTAS: boas práticas!
Apresente-se e deixe claro o seu objetivo; foco é essencial;
Garanta a confidencialidade das informações e anonimato das respostas;
Fique atento às emoções e expressões do entrevistado. Muitas informações são colhidas por meio de comunicação não-verbal;
Deixe o entrevistado à vontade, lembrando que uma ação provoca uma reação: ao se mostrar indiferente ao entrevistado, ele possivelmente desenvolverá uma reação de defesa, deixando de informar o que interessa;
Mantenha a imparcialidade durante as perguntas: é a opinião dele que interessa;
Encadeie os assuntos de forma lógica, criando ganchos na conversa que possibilitem a mudança de assunto;
Equilibre profundidade e superficialidade das perguntas.
TUDO SÃO DADOSPHP Conference 2008
QUESTIONÁRIOS: boas práticas!
Peça somente a informação que realmente pode ser fornecida;
Disponha as perguntas em uma seqüência lógica e defina suas prioridades;
Formule perguntas claras, evitando dupla interpretação;
Seja o mais breve possível: ninguém gosta de responder um questionário sem fim;
Informar na carta que acompanha o questionário o tempo estimado para o preenchimento;
Caso exista algum padrão com que se possa comparar as repostas obtidas, dê preferência a perguntas fechadas, oferecendo apenas as alternativas esperadas;
Evite abreviações, termos tendenciosos ou sugestivos;
Numere as perguntas para evitar confusão;
Ofereça anonimato aos entrevistados.
TUDO SÃO DADOSPHP Conference 2008
JAD: IMERSÃO E TRABALHO EM EQUIPE!
Existem três tipos básicos de reuniões de projeto:
sessões estratégicas, onde são discutidos o âmbito, objetivos, recursos, políticas e mudança organizacional;
sessões de dados e processos, onde se constrói ou aperfeiçoa os diagramas de fluxo de dados e modelos de dados;
sessões de telas e relatórios, onde se definem as entradas e saídas dos sistemas.
TUDO SÃO DADOSPHP Conference 2008
JAD – IMERSÃO E TRABALHO EM EQUIPE!
A metodologia está dividida basicamente em três partes:
1.Reunião inicialSão estabelecidos os principais objetivos do projeto e planejado o trabalho.
2.Reunião de revisãoÉ feita uma revisão relativa à reunião inicial, avaliada a situação das tarefas previstas e identificados os problemas e suas possíveis correções, buscando atingir a terceira etapa dentro dos prazos estabelecidos.
3.Sessão de designSão desenvolvidos os projetos de interface da aplicação enfocada.
A sessão de design é a reunião mais importante do processo. Dela devem participar todas as pessoas escolhidas na reunião inicial e confirmadas na reunião de revisão. Normalmente, a cada atividade da sessão, são atribuídos tempos previstos, procurando determinar a quantidade necessária de reuniões.
TUDO SÃO DADOSPHP Conference 2008
E o que a MODELAGEM DE DADOS tem a ver com tudo isso?
TUDO!Assim como para o desenvolvimento de sistemas de software, também para a modelagem de dados o fator mais importante é a interação entre a equipe técnica e o cliente.
Sem a compreensão do problema e do contexto onde ele está inserido e sem a compreensão das soluções propostas durante a especificação do sistema, todo o esforço até aqui pode ser desperdiçado por um modelo de dados ruim.
TUDO SÃO DADOSPHP Conference 2008
TUDO SÃO DADOS!
DADOS
São valores brutos, registros que são armazenados. Dados são estáticos, ou seja: eles permanecem da mesma forma do início ao fim de qualquer processo, a menos que sejam modificados por algum usuário ou funcionalidade da aplicação.
INFORMAÇÃO
É o dado dentro de um contexto onde ele faça sentido e ganhe significado. Um único dado pode representar inúmeras informações diferentes - tudo depende do contexto onde ele é apresentado e do público a quem ele será exibido.
AQUILO QUE PARA O SEU CLIENTE É INFORMAÇÃO,PARA VOCÊ SEMPRE SERÁ DADO!
TUDO SÃO DADOSPHP Conference 2008
ANÁLISE E MODELAGEM DE DADOS
O processo de análise e modelagem de dados tem por objetivo principal definir um modelo claro, conciso e equilibrado da realidade, sem qualquer influência dos meios computacionais que utilizaremos para resolver o problema.
Os dados gerados para ou pelo produto em desenvolvimento a fim de resolver determinado problema devem ser absolutamente independentes da tecnologia que será utilizada para interpretá-lo, fornecê-lo ou consumí-lo.
Construir o modelo de dados é um processo evolutivo e se modifica à medida que a realidade é conhecida.
Uma modelo de dados representa uma visão parcial da realidade do cliente ou produto. Cada visão da realidade tem vocabulário e regras definidas, que representam as próprias regras do negócio.
TUDO SÃO DADOSPHP Conference 2008
BENEFÍCIOS DA MODELAGEM DE DADOS
O Modelo nasce no mundo do Usuário e do Negócio e, portanto, fornece um ponto focal para discussões sobre o que é importante para o desenvolvimento do produto em questão.
As fases iniciais do processo são oportunidade real para os profissionais de Negócios se depararem com discussões sobre seus assuntos com profissionais de outras áreas, numa situação nova de compartilhamento de interesses e solução de conflitos;
As reuniões de planejamento levam a uma linguagem comum para o assunto tratado e normalmente a fluidez de comunicação entre os participantes melhora;
As fases iniciais estruturam meios de troca de uma grande quantidade de informação entre as áreas envolvidas, além de uma enorme transferência de conhecimento de Negócios para os profissionais de TI. As fases finais levam resíduos dessa transferência aos profissionais que irão implementar a solução;
Os participantes acabam percebendo melhor como suas atividades se acomodam em um contexto mais amplo. Com o passar do tempo, há ganho em valores e reforço no senso de cooperação.
TUDO SÃO DADOSPHP Conference 2008
BENEFÍCIOS DA MODELAGEM DE DADOS
Discussões sobre as funções que serão executadas pelo sistema sempre mostram novos requerimentos de dados; discussões sobre os dados e sua estrutura sempre mostram novos requerimentos funcionais.
Dessa forma, é importante desenvolver simultaneamente o Modelo de Dados e o Modelo Funcional.
Enquanto os Modelos Funcionais descrevem "como" os requisitos serão atendidos pelo sistema, os Modelos de Dados descrevem "o quê" será atendido e "por quem".
TUDO SÃO DADOSPHP Conference 2008
MODELO DE PROCESSOS DE MODELAGEM DE DADOS
ENTIDADESTABLES
CHAVESPRIMARY KEY, FOREIGN KEYS,
INDEXES
ATRIBUTOSCOLUMN
TRANSFORMAÇÃOSQL DUMP
ESCOPO
MO
DELO
LÓG
ICO
FÍSIC
O
TUDO SÃO DADOSPHP Conference 2008
MODELO DE PROCESSOS DE MODELAGEM DE DADOS
NÍVEL 1: ENTIDADES
Identificam-se os principais atores do Modelo de Dados.
NÍVEL 2: CHAVES
Para cada entidade identificada, definem-se seus chaves de identificação e os relacionamentos entre elas. A partir desses relacionamentos, e com a especificação correta das cardinalidades entre eles, é que as regras de negócio são implementadas no Modelo de Dados.
NÍVEL 3: ATRIBUTOS
Pode ser dividido em dois sub-níveis: detalhamento e normalização. No primeiro, todas as estidades são qualificadas e descritas em detalhes; no segundo, os atributos são levados da 1ª à 3ª Forma Normal, garantindo a consistência do Modelo em questão.
TUDO SÃO DADOSPHP Conference 2008
CARDINALIDADE
É a regra do Modelo de Dados que estabelece quantas vezes um registro da entidade-pai poderá se relacionar com um único registro da entidade-filha. Esses relacionamento são chamados FOREIGN KEYS.
As cardinalidades possíveis de implementação são:
• UM para ZERO, UM ou mais;• UM para UM ou mais;• UM para ZERO ou UM;• ZERO para ZERO, UM ou mais;• ZERO para UM ou mais;• ZERO para ZERO ou UM.
TUDO SÃO DADOSPHP Conference 2008
EXEMPLO DE MODELO DE DADOS COMPLETO
TUDO SÃO DADOSPHP Conference 2008
REGRAS PARA A MODELAGEM DE DADOS: ENTIDADES
Unicidade e não nulificação das chaves primárias
Chaves primárias são os identificadores únicos de cada registro. Podem ser compostas por quantos atributos forem necessários para garantir a unicidade de identificação, sem, porém, conter valores nulos nos elementos que a compõe.
Processos
Define quais eventos e como os processos de negócio acessam, modificam, excluem e incluem as ocorrências das entidades. A partir dessas regras, em conjunto às Regras do Negócio, são definidas as estruturas de functions e stored procedures do Modelo de Dados.
Estado e Transição de Estado
Define os estados possíveis de serem assumidos pela entidade, aumentando o entendimento sobre a dinâmica de seu mecanismo. Define também as causas que motivam as mudanças de estado das entidades, permitindo identificar eventos temporais e mecanismos disparadores associados (triggers).
TUDO SÃO DADOSPHP Conference 2008
REGRAS PARA A MODELAGEM DE DADOS: RELACIONAMENTOS
Também chamada de “Integridade Referencial”, define o comportamento das entidades em relação as operações de inclusão, deleção e modificação nas entidades relacionadas. São opções de configuração para as regras de relacionamento:
CASCADE; RESTRICT; SET NULL; SET DEFAULT; NONE.
TUDO SÃO DADOSPHP Conference 2008
REGRAS PARA A MODELAGEM DE DADOS: ATRIBUTOS
Nomenclatura
O nome do atributo deve ser claro e suficientemente descritivo a fim de retratar a semântica de seu conteúdo.
Hierarquia e filiação
Os atributos devem ser definidos de forma coesa, pertencendo a uma ou mais entidades, dependendo da sua função (identificação, relacionamento ou qualificação).
Formatação e validação
Os atributos devem ser definidos dentro do conceito de domínio, onde são explicitados o seu formato, regras de derivação, validação e manipulação, valores iniciais, formatação e apresentação.
TUDO SÃO DADOSPHP Conference 2008
REGRAS PARA A MODELAGEM DE DADOS: DERIVAÇÃO
Definem os meios de obtenção de um registro. A partir delas é possível obter um dado a partir de outros dados, seus relacionamentos, domínios e máscaras.
Registros simples são obtidos de maneira direta em sua entidade de origem;
Registros complexos geralmente têm suas regras de derivação compostas por combinações de fórmulas de cálculo e lógicas de associação.
TUDO SÃO DADOSPHP Conference 2008
REGRAS PARA A MODELAGEM DE DADOS: NEGÓCIOS
São regras específicas que uma empresa estabelece para funcionamento do seu negócio. Objetivamente, estabelecem as regras validação das entidade identificadas, seus atributos e relacionamentos.
Além disso, são as regras de negócio que definem e especificam as interrelações do Modelo de Dados com a Aplicação, assim como da Aplicação com o Usuário.
Regras de Negócios bem definidas auxiliam ainda na interpretação semântica da aplicação e do banco de dados e seus componentes lógicos (classes, triggers, functions, stored procedures, etc.), garantindo melhores perspectivas para futuro reaproveitamento e encapsulamento de procedimentos comuns.
TUDO SÃO DADOSPHP Conference 2008
INTEGRIDADE REFERENCIAL
Uma vez que um banco relacional se apóia em entidades e seus atributos para implementar relacionamentos (FOREIGN KEY), a integridade dos dados nos atributos chave (PRIMARY KEY) é fundamental.
Após a definição das entidades e seus relacionamentos, o passo mais importante do processo é definir a regra de propagação destes. Para cada um deles é necessário definir qual ação deve ser tomada em caso de inserção, alteração ou deleção do registro pai.
O slide a seguir define cada uma das configurações possíveis para a propagação de alterações nas PRIMARY KEYS .
TUDO SÃO DADOSPHP Conference 2008
CASCADESempre que um registro da entidade-pai modificado, todas as instâncias de relacionamento com uma entidade-filha sofre a mesma ação, por cascata.
RESTRICTModificações na entidade-pai são proibidas caso existam instâncias de relacionamento em qualquer entidade-filha.
SET NULLSempre que um registro da entidade-pai modificado, todas as instâncias de relacionamento com uma entidade-filha recebem o valor NULL.
SET DEFAULTSempre que um registro da entidade-pai modificado, todas as instâncias de relacionamento com uma entidade-filha recebem o valor padrão definido para aquele atributo.
NONEIndependente da modificação na entidade-pai, nenhuma ação é realizada no registro da entidade-filha.
TUDO SÃO DADOSPHP Conference 2008
NORMALIZAÇÃO DO MODELO DE DADOS
É o conjunto de regras que objetiva o maior refinamento possível do Modelo de Dados inicial, garantindo que o resultado final não contenha qualquer redundância lógica.
Importante: um Modelo de Dados completamente normalizado não leva em conta considerações de performance, nem o SGBD onde o sistema será implementado. Durante o desenvolvimento do projeto, a análise de performance poderá provocar modificações do modelo canônico.
TUDO SÃO DADOSPHP Conference 2008
NORMALIZAÇÃO DO MODELO DE DADOS: 1ª FORMA NORMAL
1. Identificar todos os grupos repetitivos;
2. Atomizar os grupos repetitivos a partir do estabelecimento de dependências funcionais entre as entidades.
TUDO SÃO DADOSPHP Conference 2008
NORMALIZAÇÃO DO MODELO DE DADOS: 2ª FORMA NORMAL
1. Aplicar a 1ª FORMAL NORMAL em sua totalidade;
2. Eliminar dependências parciais entre os atributos e a chave primária.
TUDO SÃO DADOSPHP Conference 2008
NORMALIZAÇÃO DO MODELO DE DADOS: 3ª FORMA NORMAL
1. Aplicar a 2ª FORMAL NORMAL em sua totalidade;
2. Garantir a dependência exclusiva entre os atributos e a totalidade da chave primária.
TUDO SÃO DADOSPHP Conference 2008
NORMALIZAÇÃO DO MODELO DE DADOS: 3ª FORMA NORMAL
TUDO SÃO DADOSPHP Conference 2008
MODELAGEM DE DADOS: boas práticas!
Em modelagem de dados em particular, assim como em desenvolvimento de sistemas em geral, é extremamente importante adotar e seguir padrões de nomenclatura de objetos. O dispêndio de tempo e esforço com esta preocupação rende um modelo conciso, claro e sem ambiguidades.
Definir as entidades de um modelo é mais do que criar sua estrutura, escolher chaves e criar relacionamentos. É preciso também criar informação que sirva para documentar a função da existência daquela entidade.
Assim como nas entidades, a definição de atributos deve ser feita de maneira clara, e valem as mesmas regras. Assim, as definições de atributos também pedem a mesma coisa: descrição, exemplo e comentários. Além disso, as definições devem ter, sempre que possível, regras de validação.
TUDO SÃO DADOSPHP Conference 2008
LEIS DE CONSISTÊNCIA DE DADOS
1. As tabelas componentes do modelo estarão na 3ªFN.
Se o modelo for desnormalizado posteriormente, controles procedurais adicionais deverão ser incluídos e documentados.
2. Não existirão duas tabelas com a mesma chave.
Se aparecerem, elas devem ser agrupadas e re-normalizadas
3. Se Y é um subconjunto da chave de uma tabela T1 e tem sentido isoladamente, deve existir uma segunda tabela T2 tendo Y como chave;
4. Se X, um atributo simples ou composto, é chave de uma tabela T1, ele é chamado atributo primário.
Nesse caso ele pode aparecer em outras tabelas, onde é chamado de chave estrangeira. Se X não é chave de nenhuma tabela, ele é um atributo secundário ou não primário e só pode aparecer em uma única tabela.
TUDO SÃO DADOSPHP Conference 2008
LEIS DE CONSISTÊNCIA DE DADOS
5. Se X, atributo simples ou composto, é chave de uma tabela T1 e aparece como atributo em uma outra tabela T2, existe uma relação hierárquica subordinando T2 a T1 segundo X;
6. Se X , atributo simples ou composto, é chave de uma tabela T1 e Y, um atributo cujo domínio é o mesmo de X, aparece em uma tabela T2, então:
a) Y não pode isoladamente ser chave de T2;b) Existe uma relação hierárquica subordinando T2 a T1, segundo T1.X <=> T2.Y
TUDO SÃO DADOSPHP Conference 2008
OBRIGADO PELA PRESENÇA!
DIEGO THOMAZ FLORESdiegotf@gmail.com
www.ecrayon.com.br
top related