Paulo Eduardo

Ha algumas semanas o orkut estava anunciando o seu novo layout, mas agora é pra valer, ao que parece todos os usuarios da comunidade eletronica já estão usando o novo layout (me corrijam se eu estiver errado).

Minhas primeiras consideraçoes pessoais:

O Visual

Pelo que pude perceber é um consenso quase global que visualmente o novo orkut é muito mellhor que o antigo, o aumento nas areas brancas do site dá muito mais levaza a nova cara, quebrando bastante o antigo azul global que tomava conta do antigo layout e que já estava “enjoando” seus usuarios.

Cantos arredondados tambem foram adcionados a algumas areas de informação proporciando um melhor fluxo de navegação.

Organização do Conteudo

O menu lateral agora concentra quase todas as funções da pagina o que facilita bastante na busca pelo local desejado.

A seçao de aniversários proximos ganhou alinhamento lateral entre os aniversarios, com isso será mais dificil encontrar listas imensas de aniversários como ocorria quando esses eram listados um em baixo do outro.

O que perdeu bastante destaque nessa atualização do orkut foram os atalhos para mensagens, fotos, comentarios e etc que se encontram logo abaixo do apelido do usuario, nessa nova versão com icones pequenos e alinhados numa unica linha.

O codigo

Não me lembro ao certo de como era o antigo codigo fonte gerado, mas levando se em considerção que o orkut é uma comunidade virtual onde diversas pessoas entram com conteudo de lugares diferentes, recados. depoimentos, textos do perfil e etc, manter um codigo totalmente semântico sem nenhum erro de marcação é uma tarefa quase que impossivel.

A nova versão tem sim seus erros de codigo, e algumas areas sem uma semantica totalmente definida marcadas somente com “divs”, tabelas ainda são usadas para posicionamento dos elementos de maneira um tanto quanto incorreta, como no caso de amigos e comunidades que não sendo dados tabulares deveriam ser marcados de maneira diferente, porem o uso dessas tabelas não é totalmente exagerado.

Conclusão

Ainda ha o que melhorar, mas essa atualização já resolveu alguns dos principais problemas anteriores do orkut.

PS: A velocidade de carregamento das paginas para mim tambem melhorou, mas as opniões com relação a isso não chegaram em um consenso ainda.

Post rapido de hoje.

Já foi falado aqui, aqui, e em muitos outros lugares sobre o 1º Encontro Brasileiro de Arquitetura de Informação que irá acontecer nos dias 19 e 20 de outubro em São Paulo.

Quem quiser ainda pode enviar seu trabalho, o prazo para submissão foi prorrogado até 05/08/2007, para mais informações entre no site ofical do evento

Esse é o primeiro grande evento a nivel nacional, especificamente sobre arquitetura da informação, uma area que cresceu muito nos últimos tempos, mas que merece ainda muito mais atenção, espero que esse seja um dos passos para esse crescimento.

Continnuando a falar sobre o Diagrama Entidade Relacionamento, nesse post vamos explicar as chaves primarias, estrangeiras e terminar nosso exemplo da locadora.

As Chaves Primarias são o atributo identificador da identidade, por isso sao únicos, ou seja não se repetem, e geralmente sao sequenciais, ou, como são chamados no SGBD, auto-increment, pois caso um atributo seja setado como auto-increment o propeio SGBD se incarrega de, caso um nova linha seja iserida a essa tabela utilizar o numero inteiro positivo imediatamente apos o ultimo utilizado. porem outros dados podem ser usados como chave primaria, como RG e CPF para cadastros pessoais e CNPJ para cadastros de empresas, pois já se sabe que esses atributos respeitam a condição de serem unicos.

Como já foi dito a representação das chaves primarias no DER e feita pelo circulo cheio seguido do nome do atributo identificador, porem na representação usado pelo DBDesigner as chaves primarias são mostradas com um desenho de chave ao lado esuqerdo do nome do atributo identificador, dentro da entidade.

Ainda existe a possibilidade de existirem chaves primarias compostas, ou seja, formadas por dois ou mais atributos, como acontece frequentemente nas entidades fracas, assim como na entidade fraca mostrada na parte anterior, nesse caso a combinação entre todas as chaves primarias não pode se repetir, porem as chaves primarias isoladamente podem se repetir.

Chaves estrangeiras são o elo de ligação entre as entidades, quando ocorre um relacionamento as chaves estrangeiras são “importadas” de uma entidade para outro, por exemplo, na ultima figura da parte anterior, no relacionamento entre cliente e aluguel a chave primaria de cliente é importada pela entidade aluguel, mostrando que aquele aluguel foi feito pelo client.

Porem como saber de que lado será colocado a chave estrangeira? É simples, num relacionamento 1-1 a chave estrangeira pode ficar em qualquer um dos lados, porem no caso de uma entidade para dados opcionais como foi dito anteriormente é recomendavel que a chave estrangeira esteja na entidade com os dados opcionais e nao na entidade com os dados obrigatorios, pois no caso de nenhum dado opcional ser inserido não ha necessidade de criação dessa chave estrangeira.

Já no relacionamento 1-N a chave estrangeira deve ficar do lado N, como no exemplo de clientes e alugueis, onde cada cliente pode fazer varios alugueis, a chave estrangeira fica na entidade alugueis (repare nonvamente no uso da palavra “cada”). Já no caso de relacionamento N-N, onde ocorre a criação de uma entidade fraca, as chaves estrangeiras ficam nessa entidade fraca, formando uma chave primaria composta, sim, é isso mesmo, a chave primaria é formada por duas chaves estrangeiras.

Com essas informações você já é capaz de realizar a sua propria documentação de banco de dados, porem nosso exemplo ainda está incompleto, faltando a seção de reserva de filmes, mostrada na figura abaixo:

Como havia dito na segunda parte da serie, nessa terceira parte iremos falar sobre como relacionar uma entidade com a outra os casos de relacionamento e como identificar cada um.

O relacionamento entre as entidades é reprentado por uma reta ligando as duas entidades com um losango localizado no centro dessa reta.

Seguindo nosso exemplo anterior um cliente, seja ele pessoa física ou jurídica, realiza locações de fitas de video ou DVD, cada locação tem sua identificação e e um atributo data, representando a data de retirada portanto a representação grafica disso, complementando a representação anterior ficaria dessa forma:

Com já havia sido falado, um losango faz a ligação entre as entidades relacionadas, porem a um detalhe que ainda não foi expllicado, a cor de cada uma das metades desse losango, essa divisão de cores representa o tipo de relacionamento entre as entidades.

No caso da locadora, cada cliente pode realizar varios alugueis, porem cada aluguel é feito por apenas um cliente (repare o uso da palavra “cada” que auxilia bastante na hora de classificar os relacionamento). Essa represntação e feita pelo DBDesigner, colorindo a metade chamada de ‘muitos’ de preto, ou seja, como cada cliente pode realizar muitos alugueis, o lado dos alugueis fica com a metade preta do losango, enquanto, como cada emprestimo e realizado por apenas um cliente, por isso a metade branca do losango aponta para a entidade cliente.

Porem essa representação é um pouco diferente da representação padrão onde teriamos algo assim:

Nessa imagem foram omitidos os atributos de cada entidade.

Como você pode ver ao inves de colorir os losangos indicando o tipo de relacionamento, em cada entidade é colocado um conjunto composto por dois caracteres entre virgulas, o primeiro caracter antes da virgula mostra o minimo do relacionamento, e o caracter apos a virgula o maximo do relacionamento.

No nosso exemplo, cada cliente pode fazer no minimo 1 e no maximo N (muitos) alugueis (1,N) e cada aluguel é realizado por no minimo 1 e no maximo 1 cliente (1,1). Essa metodologia mostra tanto o minimo quanto o maximo de um relacionamento, enquanto o DBDesigner só demonstra o maximo.

Alguns de voces podem estar pensando que um cliente pode ter um cadastro na locadora e nunca ter alugado nenhum filme, realmente isso pode acontecer, o que mudaria o minimo para 0 ao inves de 1, mas isso dependeria do modo como a locadora trabalha o cadastro de clientes, dado esse que deve ser levantado junto ao cliente em cada caso.

Apesar da metodologia padrão usar o minimo e o maximo, o mais importante num relacionamento é o seu maximo, que vai definir em qual das duas entidades será colocada a chave estrangeira, que faz a ligação entre as duas entidades no SGBD.

Mas antes de explicar as chaves estranjeiras vou mostrar todos os tipo de relacionamentos possiveis e uma explicação sobre eles:

Relacionamento 1-1

Esse relacionamento ocorre quando ambas as entidades se relacionam com maximo 1 para com a outra, não é um relacionamento muito usado já que na maioria dos casos quando uma entidade se relaciona dessa forma com a outra elas podem ser fundidas em apenas uma entidade, porem em alguns casos pode-se guardar infomaçoes opcionais sobre uma entidade em outra entidade, evitando assim que uma tabela de banco de dados tenha muitos atributos com valor nulo, caso todos esses valores opcionais fossem nulos não haveria nem a necessidade da criação de uma nova linha na entidade que porta esses dados opcionais

Relacionamento 1-N

É o tipo de relacionamento mais usado em banco de dados relacionais ocorrendo com o relacionamento maximo de uma tabela para outra é 1 e na ordem inversa é N, sendo esse o que foi usado no exemplo anterior e explicado atravez dele

Relacionamento N-N

Ocore quando ambas as entidades se relacionam com no maximo N para com a outra, nesse caso ocorre a criação de uma entidade fraca entre essas entidades para guardar o relacionamento entre essas duas atravez de suas chaves extrangeiras, no exemplo da locadora esse relacionamento pode ser encontrado no relacionamento entre alugueis e filmes representado abaixo:

Como se pode perceber, o DBDesigner transforma altomaticamente um Relacionamento N-N em dois relacionamento 1-N, a entidade fraca possui somente os ID`s das duas entidades com as quais se relaciona, porem pode ter outros atributos tambem.

No proximo topico iremos falar sobre Chaves Primarias e Estrangeiras e terminar nosso exemplo.

Como prometi no artigo anterior, vamos ao exemplo:

O primeiro passo para definir um banco de dados é encontrar no seu levantamento as entidades que o compões, no caso da locadora citada no artigo anterior elas são: cliente (pessoa fisica ou juridica), filmes, aluguel, e reserva. Em seguida definimos os atributos de cada entidade, os atributos são os dados que ficaram salvos sobre cada entidade.

Vamos usar o exemplo de clientes: os clientes tem nome, endereço, telefone e etc, porem no caso de clientes, alguns possuem CNPJ e outros CPF, por isso nesse momento é necessário o uso da especialização, como mostra a img abaixo:

Como vocês podem ver a simbologia utilizada pelo DBDesigner é um pouco diferente da teoria apresentada, mas em resumo, os atributos sao colocadas dentro da entidade, juntamente com o tipo de dados que sera utilizado para esse atributo, e o triangulo que representa uma especialização é representado por uma seta apontando da especialidade para sua entidade generalizadora.

Usando a metodologia padrão representariamos da seguinte forma:

Na proxima parte veremos como relacionar uma unidade com a outra, os casos de relacionamento e como identificar cada um.