TUDO SÃO DADOS! DIEGO THOMAZ FLÔRES www.ecrayon.com.br PHP 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 .

ALGUNS CASES

“ 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

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ódigo 1994: 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 defeituosos 300 falhas em marcapassos por semana: 500 erros em operações médicas por dia: 16.000 cartas perdidas nos correios 18 quedas de aviões por hora: 22.000 cheques descontados incorretamente

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

MODELOS DE PROCESSOS DE SOFTWARE: LINEAR ou CASCATA Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção

MODELOS DE PROCESSOS DE SOFTWARE: PROTOTIPAÇÃO construa/revise o protótipo teste do protótipo pelo cliente ouça o cliente

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.

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.

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".

MODELO DE PROCESSOS DE MODELAGEM DE DADOS ENTIDADES TABLES CHAVES PRIMARY KEY, FOREIGN KEYS, INDEXES ATRIBUTOS COLUMN TRANSFORMAÇÃO SQL DUMP ESCOPO MODELO LÓGICO FÍSICO

EXEMPLO DE MODELO DE DADOS COMPLETO

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.

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 .

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.

NORMALIZAÇÃO DO MODELO DE DADOS: 3ª FORMA NORMAL

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 .

OBRIGADO PELA PRESENÇA! DIEGO THOMAZ FLORES [email_address] www.ecrayon.com.br