WEB AULA 1 UNIDADE 1 INTRODUO Quando o assunto sistemas voltados para o ambiente internet/web, o quesito banco de dados toma

a uma importncia de maior proporo, pois a segurana dos dados torna-se fundamental alem de um bom desempenho, lgico. Dividimos o nosso estudo em alguns captulos que vo desde a modelagem de dados, passando pelo processo de normalizao at chegarmos a uma arquitetura de banco de dados voltado para a web. 1.1 modelo entidade relacionamento O modelo entidade relacionamento, que foi idealizado por Peter Chen, vem sendo utilizado desde a dcada de 70. Este modelo prega a identificao e organizao dos dados que se pretende armazenar, tudo isto obedecendo s regras do negcio em questo e que vo permitir a integrao e entrelaamento dos dados. O projeto de banco de dados envolve as etapas de construo do modelo conceitual de dados, do modelo lgico de dados e do modelo fsico de dados. Estes modelos so projetados e desenhados com figuras geomtricas pr-estabelecidas, onde esta representao recebe o nome de diagrama entidade relacionamento (DER).

As figuras geomtricas utilizadas como padro so: - retngulo, representando as entidades;

- losango, representando os relacionamentos;

- elipses, representando os atributos;

- linhas, representando e unindo as figuras geomtricas umas nas outras;

Modelo Conceitual Nesta fase inicial do projeto de banco de dados, devemos representar o nosso cenrio sistmico o mais prximo da realidade do nosso usurio, sempre colocando o armazenamento dos dados de uma forma que possa haver a compreenso do que se pretende guardar com como ser guardado. Podemos citar um exemplo onde o nosso usurio deseja armazenar as informaes e dados de um livro fiscal, ele apresenta o livro fiscal tradicional, e o analista de sistemas tem que visualizar esta necessidade e criar uma estrutura de armazenamento de forma lgica e que possa guardar de forma organizada e segura todos estes dados. Figura 1 - Livro fiscal e o modelo de dados livro_fiscal

No modelo conceitual, no devemos ou precisamos nos preocupar com qual Sistema Gerenciador de Banco de Dados (SGBD) vai ser utilizado, pois esta necessidade ser debatida nas prximas fases do projeto de banco de dados. O modelo conceitual nos permite em um nico relacionamento a participao de trs ou mais entidades, uma vez que o levantamento de requisitos do sistema pode apontar para uma regra de negcio que envolva ou apresente esta necessidade. As ferramentas CASE (Computer Aided Software Enginneering) que trabalham a fase de modelagem de dados, geralmente permitem a

realizao dos trs modelos de banco de dados (conceitual, lgico e fsico). Inclusive, fazem a transformao de um modelo para outro de forma automatizada e seguindo as regras do Modelo Relacional Normalizado. Podemos citar como exemplo de ferramentas CASE que trabalham com banco de dados, o DBDesigner o (empresa 2000 fabFORCE.net www.fabforce.net ), o Rational System Architect (empresa (empresa IBM www.ibm.com.br/software), Oracle www.oracle.com.br), o Designer Data Erwin Modeler

(empresa CAwww.ca.com). No modelo conceitual, ns tratamos apenas de entidades,

relacionamentos, atributos e as cardinalidades do relacionamento. No tratamos de chaves primrias ou estrangeiras, inicialmente so chamadas de atributos identificadores. Figura 2 - Atributos identificadores

Os atributos so referenciados apenas como caracteres, numricos, alfanumricos ou datas, ou seja, seus domnios no so totalmente especificados ainda. possvel j acrescentar a quantidade/tamanho dos atributos tambm, mas nada, alm disso.

Modelo Lgico O Modelo Lgico j mais voltado especificamente ao pessoal de tecnologia da informao, pois o tecniques ou informatiques j fica mais evidente. Ao invs de utilizarmos entidades, agora j chamamos de tabelas, os atributos so chamados de campos ou colunas. Comeamos a pensar na obrigatoriedade ou no do campo, nos formatos possveis, nas representaes que sero gravadas dentro do banco de dados. Algumas ferramentas CASE j aproveitam para determinar qual o SGBD a ser utilizado e comeam inclusive a trazer caractersticas e necessidades da parte fsica para esta etapa. No Modelo Lgico j no mais possvel representar um

relacionamento ternrio entre trs ou mais entidades/tabelas, com isto, apenas relacionamentos binrios so permitidos, levando a necessidade de normalizar o projeto de banco de dados antes. Para transformar o Modelo Conceitual em um Modelo Lgico, algumas ferramentas CASE j aplicam algumas regras pr-estabelecidas e resolvem alguns dos problemas de modelagem, porm, algumas delas no fazem de forma to automtica assim, sendo necessrio a interveno humana na sua resoluo. Somente relacionamentos binrios so permitidos no Modelo Lgico, pois uma das principais caractersticas do Modelo Entidade Relacionamento fica explicito neste modelo. O conceito de chave primria e chave estrangeira so estabelecidos, onde o principal ponto da integridade referencial concretizado. Este conceito diz que a chave primria de uma tabela referenciada em outra tabela como uma chave estrangeira, estabelecendo assim

um relacionamento. A quebra deste relacionamento compromete a integridade e a consistncia dos dados das tabelas envolvidas. Do lado chave primria, sabemos que s pode haver uma ocorrncia de um determinado contedo, mas do lado chave estrangeira, a nulidade, a presena nica ou a presena de vrias ocorrncias vai depender da regra de negcio estabelecida pelo relacionamento, mas o SGBD vai seguir fielmente esta regra que for implementada e vai garantir o cumprimento integral da mesma. Aqui podemos apresentar algumas das regras que so inerentes a uma chave primria ou uma chave estrangeira. - o contedo de uma chave primria uma vez estabelecida, no pode ser modificado, ou seja, sofrer um update. - uma ocorrncia da tabela (registro) s pode ser removida se a mesma no tiver nenhum registro em outra tabela relacionada, ou seja, no possui referencia em outras tabelas. - se uma ocorrncia da tabela (registro) tiver que ser removida, todos os registros da tabela referenciada dever ser removido tambm (chamamos de infanticdio ou deleo em cascata) ou ento a deleo original no poder ser executada. - uma ocorrncia da tabela (registro) referenciada pode ser removida sem a necessidade de nenhuma validao adicional (deletar um registro filho sem afetar o registro pai ou os demais registros irmos).

Modelo Fsico Aqui, estamos tratando j dos comandos padro SQL para a criao fsica do banco de dados, com as caractersticas e sintaxes apropriadas ao SGBD escolhido. Em linhas gerais, o projeto fsico contm uma srie de comandos CREATE e ALTER. Dependendo do SGBD adotado, ele pode ter uma sintaxe muito parecida com outro SGBD, mas sempre que for necessrio utilizar um projeto fsico de um SGBD especfico em outro SGBD, uma reviso completa de sintaxe deve ser feita, seno voc corre o risco do seu projeto fsico no funcionar de acordo com o esperado. Normalmente como o Modelo Fsico j esta ajustado sintaticamente para um SGBD, caso o mesmo projeto seja utilizado em outro SGBD, provavelmente alguns trechos e formatos dos comandos devero ser ajustados. Isto faz com que um Modelo Fsico seja especfico de um determinado banco de dados, em muitas situaes at mesmo a diferena de verso do mesmo SGBD faz com que o Modelo Fsico seja ajustado. Uma prtica comum em empresas que desenvolvem software manter um projeto de banco de dados sempre no Modelo Lgico, que independente de SGBD e na hora de montar o seu Modelo Fsico, adequar o software para o SGBD desejado e assim a sintaxe gerada para o Modelo Fsico ser de acordo com o software desejado e na verso correta tambm. As ferramentas CASE permitem que no momento de transformar o seu Modelo Lgico em um Modelo Fsico, seja possvel escolher o SGBD desejado e at mesmo a verso do software, para que a sintaxe seja a mais prxima possvel do que vai ser utilizado e assim evitar erros de sintaxe ou mesmo a interveno humana no script de criao.

<http://www.devmedia.com.br/conceitos-fundamentais-debanco-de-dados-parte-2/1678>

1.2 Modelo Relacional Normalizado Conceito e necessidade de normalizao O Modelo Entidade Relacionamento tenta se aproximar o mximo possvel da representao do cenrio sistmico e por isso mesmo no est totalmente aderente s melhores formas de garantir a integridade e consistncia dos dados. Por isso, uma srie de situaes pode levar o banco de dados a comprometer suas principais caractersticas de funcionamento e validao ou at mesmo comprometer o seu armazenamento de dados de forma organizada. A consistncia dos dados fundamental para a confiabilidade do banco de dados. Com isto, algumas regras foram desenvolvidas para refinar e melhorar a estrutura de armazenamento dos dados. Estas regras receberam o nome de Formas Normais e a sua aplicao e resultado final ficou conhecida como Modelo Relacional Normalizado.

A execuo ou o processo de aplicao das regras referenciado como Normalizao do banco de dados ou Normatizao do banco de dados, para entender um pouco mais do significado destas palavras, veja o seguinte link. <http://usuarios.cultura.com.br/jmrezende/normatizar.htm> <http://www.abtg.org.br/index.php?option=com_content&ta sk=view&id=212&Itemid=47> O seu modelo de dados sem nenhuma reviso conhecido como Modelo Desnormalizado, este o seu ponto de partida. A sua aplicao sequencial do Modelo Desnormalizado para a Primeira Forma Normal, depois da Primeira Forma Normal para a Segunda Forma Normal, depois para a Terceira Forma Normal e se for necessrio, passar pela Boyce Codd Forma Normal e Quarta Forma Normal. A 1FN, a 2FN e a 3FN so obrigatrias e resolvem praticamente todas as situaes de normalizao. A BCNF e 4FN so necessrias apenas em situaes especiais. Alguns especialistas de banco de dados j pregam a Quinta Forma Normal (5FN), porm so situaes muito pontuais e especificas, nem sempre usual em sua ocorrncia.

Primeira Forma Normal Para transformarmos um modelo de dados da sua forma

desnormalizada para a Primeira Forma Normal, devemos procurar por atributos repetidos dentro das entidades, ou seja, identificar os atributos que possuam o seu domnio repetido e que demonstrem assim a existncia de vrias ocorrncias do mesmo atributo na entidade.

Depois

de

identificar

estes

atributos,

os

mesmos

devem

ser

removidos e separados em uma nova entidade. Nesta nova entidade, voc no precisa colocar todas as repeties retiradas, apenas uma destas ocorrncias o suficiente; uma vez que necessrio estabelecer um relacionamento forte de 1-N, onde a chave primria da entidade forte vai ser uma chave estrangeira na entidade fraca e tambm far parte da chave primria desta entidade fraca. Quadro 2 - Desnormalizado Conceitual

Quadro 3 - Desnormalizado Lgico

1 FN Conceitual

1 FN Lgico

Segunda Forma Normal Na Segunda Forma Normal, devemos identificar e eliminar todas as dependncias funcionais parciais, dos atributos no chave com partes da chave primria. Os atributos que apresentarem esta dependncia devero ser separados em uma nova entidade e um relacionamento forte deve ser estabelecido entre elas para que a chave primria composta continue assim. Uma observao importante pode ser afirmada com relao s entidades que possuam chave primria simples, estas entidades no podem conter dependncias funcionais parciais da sua chave primria, portanto estas entidades j esto na Segunda Forma Normal automaticamente. 2 FN Conceitual

2 FN Lgico

Terceira Forma Normal A Terceira Forma Normal analisa a dependncia funcional dos atributos no chave com os outros atributos no chave, deixando a chave primria de fora desta vez. As dependncias que forem identificadas devero ser transferidas para uma nova entidade e o relacionamento que dever ser estabelecido para manter esta nova entidade, um relacionamento fraco. Outro ponto observado na Terceira Forma Normal referente aos atributos calculados. Atributos que tenham o seu valor determinado por uma ao imposta em outras colunas no devem ser armazenados, pois podem ser calculados em tempo real sempre que forem necessrias a sua apresentao. O exemplo mais tradicional desta situao o valor total da nota fiscal, pois um atributo que depende do valor individual de cada item da nota fiscal. Para o exemplo, vamos acrescentar o atributo nom_atendente dentro da comanda e atributo val_comanda na entidade Comanda e tambm o atributo val_produto na entidade Produto.

Aps aplicar a 3 FN 3 FN Conceitual

3 FN Lgico

Boyce Codd Forma Normal A situao tratada pela BCFN foi descoberta pelos irmos Boyce, como as Formas Normais j estavam todas definidas e difundidas, para no houvesse uma renumerao ou redistribuio das Formas Normais, uma vez que esta regra deveria ser executada entre a Terceira Forma Normal e a Quarta Forma Normal, convencionou-se chamar de Boyce Codd Forma Normal.

A BCNF verifica uma situao de dependncia funcional entre chaves primrias compostas, ou seja, quando uma parte de uma chave primria depende funcionalmente de outra parte da chave primria, causando uma situao onde no possvel identificar individualmente uma entidade dentro deste conjunto de entidades semelhantes. Isto significa que a chave primria composta precisa ser revisada, um novo atributo dever fazer parte desta chave primria composta ou ento uma parte desta chave primria composta dever ser trocada ou substituda. Em linhas gerais, significa que na fase onde as chaves eram tradas como chaves candidatas, no houve uma escolha mais criteriosa ou ento todas as possibilidades de combinao no foram testadas. Resumindo, a BCNF deve ser executada quando a chave primria composta no est executando a sua funo primordial de identificao individual. Geralmente ,quando o analista cria um atributo ID ou COD e pensa num identificador ou cdigo, onde ele mesmo vai decidir e estabelecer qual o domnio deste identificador ou cdigo, porque ele no encontrou nenhum outro atributo na entidade que permita ou possibilite a funo de chave primria, com isto ele puxa a responsabilidade de criar um atributo que vai conter um valor controlado e no repetido. Assim a Boyce Codd Forma Normal acaba sendo desnecessria. Ex. uma entidade Produto modelada para um pequeno comrcio.

Veja que com os atributos nome_produto e descricao_produto escolhidos como chave primria (atributos identificadores no modelo conceitual) podemos ter o seguinte cenrio: - nome_produto = tota-tola - descricao_produto = refrigerante gasoso sabor tola - tipo_embalagem_produto = garrafa vidro - peso_produto = 600 ml - data_validade_produto = 31/12/2012 - valor_produto = 3,00 - e um segundo produto com: - nome_produto = tota-tola - descricao_produto = refrigerante gasoso sabor tola - tipo_embalagem_produto = lata alumnio - peso_produto = 350 ml - data_validade_produto = 31/12/2012 - valor_produto = 2,50

Veja que os produtos so iguais em nome e descrio, mas diferenciam-se no tipo de embalagem, no peso e no valor. Neste caso, fica evidente que os dois atributos escolhidos no so uma boa escolha. A soluo seria acrescentar mais um atributo como identificador ou ento, fazer o tradicional que criar um novo atributo com a descrio de Identificador ou Cdigo, trazendo a responsabilidade do seu domnio para o sistema. Quarta Forma Normal A 4FN trata de relacionamentos ternrios (multivalorados) que podem ser modelados no plano conceitual. Normalmente, relacionamento no com modelo mais conceitual de duas podemos entidades, montar este tipo um de

relacionamento recebe o nome de relacionamento ternrio ou n-rio.

Exemplo de relacionamento binrio

Exemplo de relacionamento ternrio com 3 entidades

Exemplo de relacionamento ternrio com 4 entidades No Modelo Lgico no podemos implementar o relacionamento ternrio, ento temos que transformar todos os relacionamentos ternrios em vrios relacionamentos binrios, voc pode montar quantos relacionamentos binrios forem necessrios para que a sua regra de negcio seja mantida.

Exemplo de um relacionamento binrio no modelo lgico

Exemplo do um relacionamento ternrio transformado em vrios binrios

Exemplo de um relacionamento ternrio transformado em vrios binrios Este exemplo acima demonstra uma situao onde o relacionamento ternrio inicial foi desmembrado em 3 relacionamentos binrios, uma situao que pode contemplar a todas as necessidades de regras de negcio. As cardinalidades neste caso no foram mantidas para efeito de demonstrao, mas no seu dia a dia, deve-se prestar muita ateno para no montar um looping de relacionamento. 1.3 Arquitetura cliente servidor A arquitetura cliente servidor, foi muito utilizada na dcada de 90 e na primeira dcada do sculo XXI. Neste cenrio, o banco de dados fica centralizado em um servidor, comumente conhecido como servidor de banco de dados e os microcomputadores que executavam os aplicativos (sistemas) eram conhecidos como clientes. Este padro ficou conhecido como client/server ou CtoS.

Os sistemas aplicativos executavam toda a lgica de programao no microcomputador e somente as requisies de dados era encaminhadas para o banco de dados, este por sua vez executava o comando SQL e retornava para a estao cliente todos os dados de resposta. Em muitos casos ou situaes, este retorno de dados de resposta gerava um alto trfego na rede. No servidor de banco de dados tambm poderiam ser executados os procedimentos e funes, que normalmente apresentavam uma performance muito melhor do que os programas da parte cliente. Uma situao muito comum era um analista/programador, em seu microcomputador, fazer um acesso interativo ao banco de dados e inadvertidamente executar um comando do tipo select * from lancamento_contabil. A tabela lancamento_contabil tem, por exemplo, 1 milho de linhas, um comando como o exemplificado, vai retornar todas as linhas da tabela. O servidor de banco de dados vai processar este comando e o resultado muito rpido; s que todos os dados retornados pelo

servidor

de

banco

de

dados

devero

ser

entregues

ao

microcomputador que executou a solicitao; com isto, todos estes dados devero trafegar na rede entre o servidor do banco de dados e o microcomputador. Pela prpria arquitetura de rede, os dados trafegados sero

entregues em uma grande fila, e vai ocasionar uma demora na entrega total ao microcomputador. Neste cenrio, o monitor do microcomputador vai ficar apresentando os dados, um a um, at chegar ao ltimo registro. S que no servidor do banco de dados, este comando j encerrou a sua execuo faz tempo. Como uma rede de microcomputadores de uma empresa geralmente tem algumas dezenas, centenas ou milhares de microcomputadores, um processamento com estas caractersticas impe uma sobrecarga na rede de dados que vai atrapalhar os demais microcomputadores.

Na arquitetura cliente servidor cada microcomputador ao acessar um banco de dados, estabelece uma sesso de comunicao e contada uma licena de acesso. Se este mesmo microcomputador atravs de outro programa que seja aberto simultaneamente ao primeiro, fizer uma nova comunicao com o banco de dados, uma segunda sesso estabelecida no banco de dados.

Dependendo da modalidade de licenciamento do software de banco de dados, voc pode ter que pagar por cada uma destas sesses abertas simultaneamente ou ento, atravs de uma licena full (que geralmente a mais cara), estabelecer quantas conexes simultaneamente voc desejar. Enquanto o seu programa que acessa o banco de dados estiver aberto ou em funcionamento (no interessa se est minimizado ou no), a conexo com o banco de dados est estabelecida e recursos de processamento e memria no servidor de banco de dados esto sendo alocados, reservados e utilizados. Por isto, quanto mais usurios estiverem conectados ao banco de dados, mais sesses de acesso ao banco estaro abertos, por isso a prpria licena de banco de dados do servidor tambm precisa ser bem planejada. Licenas do tipo Standard geralmente possuem limitaes de

funcionalidade e possuem um valor menor, j as licenas do tipo Enterprise tm todas as funcionalidades embarcadas ou liberadas e custam mais caro. Uma prtica comum das empresas proprietrias dos SGBD no limitar a quantidade de usurios conectados no banco, mas elas realizam auditorias peridicas para verificar se o nmero de usurios conectados ao bancode dados condiz com a quantidade de licenas de acesso que foram adquiridas. Diante destas caractersticas normalmente um sistema nasce com poucos acessos e ao longo do seu ciclo de vida, a quantidade de usurios aumenta muito assim, aquele consumo inicial que era pequeno, pode aumentar muito e comprometer o sistema todo, caso o equipamento no disponha de todo este recurso de processador e memria. Existe at mesmo um estigma no mercado que diz:

Um banco de dados consome todos os recursos de um servidor, quanto mais memria e processador voc disponibilizar para ele, mais ele vai consumir. Esta frase reflete o crescimento voraz de recursos que um sistema de banco de dados tem, pois a cada dia o nmero de usurios e novos sistemas implantados s aumentam nas empresas. Para tentar suprir um pouco este crescimento no consumo por recursos computacionais que as empresas apresentam, a indstria de informtica criou o conceito de vrios processadores no mesmo servidor ou ento o empacotamento de vrios ncleos de processamento em um mesmo processador. Este recurso veio amenizar as necessidades constantes de trocas de equipamento, porm os fabricantes de SGBD observando este cenrio mudaram as suas estratgias de vendas e licenciamento de software. Passaram a cobrar pela quantidade de processadores e ncleos. Por isso tudo, durante a elaborao de um projeto de sistemas, o assunto infra-estrutura no pode ser subjugado e muito menos deixado para depois, porque seno, os custos posteriores podem fazer com que o valor inicial do projeto fique muito fora do planejado e pode levar at mesmo ao cancelamento do projeto. Vamos imaginar um cenrio: Uma empresa com 500 funcionrios e completamente automatizada em seus principais processos. Um sistema de ERP em um servidor com 500 usurios conectados a ele. Um sistema de CRM em outro servidor com os mesmos 500 usurios. Um sistema de SCM em outro servidor com 500 usurios tambm.

Os custos de licenciamento de banco de dados podem elevar o valor do projeto para cifras altssimas. Pois apesar de ter 500 usurios, voc vai precisar de 500 licenas em cada um dos servidores e o seu custo ser o equivalente a 1.500 usurios. Diante de um cenrio complicado como estes, uma nova arquitetura de acesso a banco de dados foi apresentado ao mercado, com o intuito de resolver vrias situaes no s de licenciamento de banco de dados, mas principalmente de arquitetura de processamento de informaes.