[10] XML

Hoje nossa turma foi apresentada às linguagens de marcação (Markup Languages), que usam tags (rótulos, marcadores) para instruir sobre o quê se deseja fazer com um determinado dado.

Começamos direto com a XML (eXtensible Markup Language), uma linguagem de marcação parecida em alguns aspectos com a HTML (Hyper Text Markup Language) porém mais poderosa e flexível, no que se propõe a fazer, com tags de livre definição. A XML foi desenvolvida para descrever e transportar dados entre nós da rede (internet ou outra), enquanto a HTML está mais voltada para a exibição de dados. A aplicação de estilos e firulas aos dados pode ser especificada com o uso da XSL (eXtensible Stylesheet Language)

Numa descrição abreviada, você: diz como quer estruturar, envelopar e transportar seus dados, com a XML ; diz como quer que eles sejam "embelezados" para apresentação, com a XSL ; mostra afinal na sua página da internet, com a HTML.

Fizemos alguns exercícios (nosso grupo, como de praxe, loosely envolving Juan, Renan, Tissiana e eu) estruturando dados com XML, que envolveram uma fase conceitual de observá-los inicialmente no velho modelo de "árvore invertida".

A "beleza" das linguagens de marcação, me parece, está em usar um arcabouço primitivo de extrema simplicidade (caracteres e arquivos texto) para obter resultados e soluções complexos. Isto cria uma razoável independência de protocolos, sistemas operacionais, hardware, etc. Afinal, "todo mundo" é capaz de gerar, ler e carregar ASCII!

Por fim, a professora nos deu o "caminho das pedras" para solucionar os problemas com a base de dados da clínica médica, apresentando uma consulta SQL que permite recuperar dados em diferença entre duas tabelas.

Ah! Em tempo: bem vindos ao Miss Blog 2007, que vai escolher uma (um?) digna representante das blogueiras (blogueiros?) fucapianas.

[9] Banco de Dados - III

Voltamos ao problema da montagem do banco de dados para a marcação de consultas de uma clínica médica, abordando-o agora à luz dos novos conhecimentos adquiridos ao longo das duas últimas aulas.

A definição dos dados a serem guardados e tabelas a serem montadas foi relativamente sopa-no-mel. A estruturação dos relacionamentos e montagem de consultas para mera visualização dos dados inseridos também pode ser classificada na categoria mamão-com-açúcar.

A coisa emperrou seriamente quando chegamos à fase de construir consultas SQL para recuperar e manipular os dados armazenados de forma que se mostrasse útil para os usuários finais do sistema (em especial a secretária e o paciente). Eu, Juan, Renan e Tissiana quebramos a cabeça, sem chegar a uma solução satisfatória.

O banco de dados obtido como produto final é responsabilidade minha. Será entregue para a professora e pode ser muito útil como exemplo de violações e transgressões às normas do modelo relacional. O pior é que não está funcionando!

De qualquer forma, valeu para o aprendizado de como é importante, mesmo para bancos de dados aparentemente simples, o esmiuçamento do problema na fase conceitual e uma detalhada e documentada estipulação do modelo relacional.

O mais valioso destas aulas foi visualizar as diferenças entre ferramentas. Por que usar um SGBD no lugar de uma planilha eletrônica? Deu pra notar que o SGBD é ferramenta mais adequada quando uma coleção de dados tem perspectiva de vir a ser muito grande, e seja atualizada constantemente.

Além disso, e mais importante: é uma ferramenta que permite diferentes formas de recuperação, visualização e manipulação dos dados sem que seja necessário alterar a estrutura onde os mesmos estão guardados (desde que estas estruturas tenham sido adequadamente especificadas e montadas).

[8] Banco de Dados - II

Querido diário

Hoje demos continuidade ao nosso aprendizado sobre o Access.

Aprendemos sobre o uso da SQL como linguagem para consulta e manipulação de um banco de dados. Usamos um "banco de testes" preparado pela professora com um sistema de reservas para companhias aéreas.

Vimos sobre o uso das cláusulas SELECT, FROM, INNER JOIN e WHERE da SQL, e de alguns operadores como AND e IN, nas consultas de seleção.

Nota 1: Levar uma caixa de bombons pra Márcia.

Vimos também o uso das cláusulas UPDATE e SET para consultas de atualização e INSERT INTO para consultas acréscimo.

Nota 2: Levar uma caixa de bombons E um buquê de flores pra Márcia.

[7] Banco de Dados - I

Querido diário

Hoje nossa turma foi conduzida ao laboratório de informática pela Profª Renata, e apresentada pela primeira vez (ou a primeira vez para a maioria da turma, pelo menos) ao Access - o sistema gerenciador de bancos de dados de uso geral da Microsoft.

Nosso objetivo, conforme colocado pela professora, será desenvolver um banco de dados para a marcação de consultas de uma pequena clínica com quatro médicas de diferentes especialidades. Não deve ser difícil. Afinal, a Márcia, secretária do meu dentista, faz isso todo dia só com a ajuda de uma pequena agenda, um lápis e uma borracha.

A professora ficou tentando nos fazer perder tempo discutindo e montando um modelo conceitual para os dados. Mas nós não estávamos dispostos a perder tempo com tais detalhes: o negócio é meter logo a "mão na massa"!

Recebemos então as primeiras noções sobre o uso do Access, com apresentação das telas do mesmo.

Depois aprendemos sobre a definição de Tabelas (onde os dados serão guardados), os campos que formam seus registros, características de cada tipo de campo, definição de chaves primárias, secundárias e estrangeiras.

Definidas as tabelas, aprendemos sobre como estabelecer os relacionamentos entre as mesmas, através das chaves.

Nota 1: A professora tinha razão. Devíamos ter perdido mais tempo com o maldito modelo conceitual.
Nota 2: Convidar a Márcia pra jantar - ela é muito mais inteligente do que eu imaginava!

[6] E-Commerce

Cada vez mais os atos imemoriais de comprar e vender vem encontrando um poderoso aliado na grande rede. Nem sempre é prático, algumas vezes é mais caro do que na loja da esquina, receber a mercadoria pode ser demorado, mas a verdade é que pode-se comprar e vender de quase tudo através da Internet.

Pensar em comércio eletrônico traz logo à lembrança a Amazon.com, possivelmente a primeira organização a galvanizar a atenção de consumidores e realizar vendas de varejo em volume quantitativo significativo na Internet. Começando como uma livraria virtual, aplicou seu bem sucedido modelo, de "entreposto" entre leitores sequiosos e editoras, a outros segmentos e hoje disponibiliza a venda, além dos livros, de CD's, eletro-eletrônicos, roupas, enfeites, móveis e mais uma série enorme de produtos.

O modelo implementado pela Amazon procura reduzir os custos e esforços de busca por parte dos consumidores, disponibiliza uma pletora de informações sobre os produtos, tentando suprir a necessidade de experimentação dos compradores (oferecendo, por exemplo, um mecanismo de "folhear virtual" dos livros), cuida de construir e manter escrupulosamente a reputação de entregar o que promete, preserva obssessivamente os aspectos de segurança na transação e preocupa-se com os aspectos logísticos da operação comercial (em parceria com FedEx e DHL, gigantes do ramo).

O modelo Amazon fez escola, e é base para outras lojas virtuais como, no Brasil, Americanas.com e Submarino (ambas controladas hoje em dia pelo grupo Americanas). Superadas as dificuldades iniciais que, no Brasil, incluíam serem poucos os consumidores com acesso à Internet e menos ainda os que dispunham de cartão de crédito (o meio de pagamento ubíquo na Internet), as lojas virtuais vem apresentando a cada ano expressivos aumentos de vendas.

A existência de lojas virtuais levou ao surgimento de sites como o Buscapé e o Bondfaro, buscadores que comparam preços e ofertas em várias lojas concomitantemente. Estes sites ainda padecem de certa desconfiança dos consumidores, pois estão longe de ser "independentes", apresentando comparações somente entre lojas a eles afiliadas (e que lhes pagam uma taxa de manutenção... ).

Numa comunidade pulverizada como é a Internet, não demoraram a surgir sites que colocavam consumidores, vendedores particulares e pequenos comerciantes em contacto. Ebay e MercadoLivre se estabeleceram como verdadeiros balcões de leilões virtuais. Apesar do inegável sucesso na parte relativa a colocar compradores e vendedores em contacto direto, estes sites ainda tem seu calcanhar de Aquiles nos aspectos de segurança e confiabilidade, mas vem procurando suprir esta deficiência disponibilizando, por exemplo, um histórico com a reputação dos vendedores e introduzindo meios de pagamento mais seguros para os compradores (como PayPal e Sedex-a-cobrar).

Como suporte aos que desejavam instalar suas lojas virtuais, apareceram então os desenvolvedores de ferramentas especializadas para a criação de sites de comércio online, como o Fast Commerce, por exemplo. Estas ferramentas podem até não ser as ideais para determinados propósitos, mas são certamente um bom e prático ponto inicial.

Pergunta do Renan

Como o e-comerce minimiza os custos de transação para o consumidor ?

Renan

Inicialmente vamos dar uma breve explicação à profª Renata, que a essa altura deve estar seriamente preocupada e curiosa com esta nossa aparente fixação em custos de transação.

Professora, estes custos são a representação dos esforços incorridos por participantes de uma transação à luz da Teoria da Firma (ou Teoria das Agências). Esta teoria propõe que todas as organizações podem ser visualizadas como uma rede de indivíduos trocando entre si bens, serviços e informações pertinentes a estas trocas. Do contacto entre "nós" (knots em inglês) desta rede nascem contratos, explícitos e/ou implícitos, que respaldam as trocas pretendidas. Eu, particularmente, procuro chamar estes nós de elos, para evitar confusão com o pronome. Estes elos são ocupados por indivíduo(s) denominados agentes. Dois agentes, uma vez em contacto, visando realizar uma transação, geralmente não possuem toda a informação sobre os atributos de itens envolvidos na transação, de forma uniforme e total: o vendedor, por exemplo, vai procurar disponibilizar e ressaltar as informações sobre as boas qualidades do produto e esconder informações sobre falhas e defeitos. O comprador, por sua vez, não tem facilmente todas as informações sobre o produto e, mesmo que as tivesse, acabaria por não usá-las devido à sua racionalidade limitada. À diferença de conhecimento sobre os atributos de um produto envolvido em uma transação chamamos de assimetria informacional. No caso exemplificado é do interesse do vendedor manter esta assimetria, e ao comprador interessa quebrá-la. Os custos de transação, portanto, representam os esforços e sacrifícios (monetários ou não) envolvidos na quebra ou manutenção da assimetria informacional, além daqueles incorridos na obtenção inicial, manutenção e preservação da informação. Um corolário presente na teoria, é de que existe um custo de oportunidade envolvido: o custo para obtenção, manutenção ou mesmo supressão de uma informação só se justifica quando se torna menor do que o custo de oportunidade (representado pelo custo de manter-se o status quo, não fazer nada). Não custa (sem trocadilho!) lembrar que tais custos não envolvem apenas valores monetários. Envolvem também valores éticos, morais, filosóficos e dependem também da percepção de cada agente sobre os mesmos.

Podemos então começar nossas reflexões sobre o tema proposto lembrando do artigo do Mario Rese que estudamos em Marketing com o prof. André Aquino. A escolha dos consumidores por produtos e/ou serviços implica (relembrando em pouquíssimas palavras) em custos de transação que envolvem atributos de busca (achar o produto), uso e experimentação (adquirir conhecimento do produto, de suas qualidades e deficiências) e reputação do vendedor (formar uma opinião sobre a probabilidade de uma experiência repetir-se).

Para o e-commerce minimizar os custos referentes a atributos de busca é fácil: ele disponibiliza ao consumidor, do conforto de sua casa, acesso imediato a variadas ofertas de fornecedores. Podem não ser todas as ofertas (o Buscapé, por exemplo, só disponibiliza consultas a lojas afiliadas), mas dependendo da percepção do consumidor e devido à racionalidade limitada, podem ser satisfatórias e suficientes.

Já os custos de experimentação constituem um "calo" nas pretensões do e-commerce: a experiência virtual, por mais informação que você agregue, nem sempre consegue suprir o contacto com o bem ou serviço real. Porém, se o produto já é conhecido do consumidor, este atributo pode perder relevância para a decisão de compra pelo mesmo.

E a reputação do vendedor precisa ser construída através da repetição de experiências bem sucedidas de compra, ou ser avalizadas por prepostos independentes em quem o consumidor confie.

A decisão em favor do comércio virtual, em detrimento da velha e conhecida loja da esquina, vai depender da percepção do consumidor sobre quanto o custo global da transação virtual economiza para o mesmo, em termos de busca, qualidade e adequação do produto obtido, preço do produto e capacidade do fornecedor em fornecer aquilo que promete, em relação à transação já conhecida com o comércio físico.

Ou seja, e-commerce não é mera questão de preços adequados. Reduzir o custo de transação para o consumidor, levando-o a optar pelo e-commerce, envolve ser fácil descobrir o preço oferecido, ter como avaliar o produto à distância, ter segurança na transação e confiança de que os resultados da transação serão os esperados e prometidos.