Após a primeira parte, que começou a comparação entre banco de dados e Excel, daremos continuidade abordando quando usar bancos de dados ou Excel, entre outros assuntos.
Bancos de dados e web
Os bancos de dados são ótimos para análise preliminar, exploração e limpeza de dados. Mas eles são ainda melhores para conectar-se a outra coisa quando você sabe o que você quer fazer com os dados. Praticamente todos os aplicativos web são alimentados por bancos de dados como esses. Quando você acessa uma conta em algum site em algum lugar, ele está verificando o seu nome de usuário e senha em um banco de dados. Quando você vai ao IMDB e clica em um filme, ele está olhando para um banco de dados. Twitter, Facebook e Gmail possuem bases de dados no caminho todo.
Quando se trata de recursos, um banco de dados geralmente é usado quando a quantidade de dados é grande ou espera-se que eles mudem ao longo do tempo. Em vez de ter um arquivo JSON estático com seus dados, você pode manter um banco de dados e escrever um aplicativo que consulta o banco de dados para os dados atuais. Então, quando os dados são alterados, tudo que você tem a fazer é atualizar o banco de dados, e as alterações serão refletidas no aplicativo. Para aplicações pontuais, em que os dados não vão mudar e a quantidade é pequena, um banco de dados geralmente é um exagero, embora você ainda possa usar um nas fases iniciais para gerar um arquivo de dados de algum tipo.
Se em vez disso você estiver usando uma API para alimentar um aplicativo com dados atuais, você ainda assim estará fazendo uso de um banco de dados, só estará deixando alguém hospedá-lo para você. Isso é muito mais fácil, mas também apresenta riscos, porque você acessa os dados segundo a vontade de quem hospeda o banco.
Potencial trocadilho semântico: às vezes, um aplicativo não está acessando diretamente um banco de dados para buscar informações. Às vezes, ele está acessando arquivos armazenados em cache, mas esses arquivos em cache são gerados automaticamente com base no que está no banco de dados.
Então, quando eu devo usar um banco de dados no lugar do Excel?
Excel e bancos de dados são bons para coisas muito diferentes. Nenhum dos dois é bom ou ruim por si só. Uma regra de ouro: você deve considerar fortemente usar um banco de dados para um projeto na medida em que as seguintes premissas forem verdadeiras:
- Você tem um monte de dados.
- Seus dados são confusos ou complexos.
- Você quer alimentar outras coisas com seus dados.
- Outras pessoas precisam trabalhar com os mesmos dados.
OK, estou intrigado. Como faço para começar?
Porque bancos de dados têm uma curva de aprendizado, faz sentido não mergulhar muito fundo de uma só vez. Comece a usá-lo apenas nos casos em que a vantagem é especialmente forte e suas necessidades são muito simples. Na medida em que seu nível de conforto aumentar, você vai cada vez mais enxergar os bancos de dados para obter o que deseja mais rapidamente.
Opção 1: SQLite
SQLite é uma boa maneira de começar. Você pode instalar a extensão “Gerenciador de SQLite” para o Firefox e fazer tudo dentro do navegador.
Um tutorial SQL baseado no SQLite: https://github.com/tthibo/SQL-Tutorial
Opção 2: Microsoft Access
Microsoft Access faz uso de SQL e apresenta uma interface de software desktop mais tradicional. Dependendo de para quem você direcionar a pergunta, a resposta será que é uma ferramenta útil ou apenas torna as coisas mais confusas. Eu, pessoalmente, não recomendo, mas sua quilometragem pode variar.
Opção 3: Configurar uma conta de hospedagem web compartilhada
Você pode configurar uma conta de hospedagem web compartilhada como um playground para brincar com isso. Isso pode custar tão pouco quanto £20 por ano. Essas contas geralmente vêm com uma interface que permite criar, editar e interagir com bancos de dados sem escrever nenhum SQL. Elas também oferecem um lugar para brincar com outras habilidades relacionadas à web nas quais você pode estar interessado e queira compartilhar os resultados com outras pessoas!
Small Orange (uma boa opção de hospedagem barata): http://asmallorange.com/
Opção 4: Instalar o MySQL ou PostgreSQL no seu computador
Você pode instalar o MAMP em um Mac ou WAMP em um PC com Windows. Isso instalará o MySQL, bem como uma grande interface web chamada phpMyAdmin. Depois de ter o MySQL instalado, você tem um monte de opções adicionais de softwares gratuitos para servir como um browser/editor para seus bancos de dados SQL. Se preferir, pode instalar o PostgreSQL no lugar, um banco de dados de sabor ligeiramente diferente (há muitos sabores diferentes de banco de dados, mas o MySQL e o PostgreSQL são dois dos mais populares com muita documentação, não amplie demais as opções por enquanto).
Apêndice: consultas para se divertir e lucrar
Muito do poder de bancos de dados relacionais vem do SQL, uma linguagem muito flexível para fazer perguntas a um banco de dados ou para dar-lhes uma ordem. A curva de aprendizagem é mais acentuada do que no Excel, mas quando você pegar o jeito dele pode responder rapidamente quase qualquer pergunta sobre seus dados. Vamos passar por alguns breves exemplos de como uma ação desejada se parece em SQL.
Os blocos de construção básicos do SQL são quatro verbos: SELECT (procurar algo), UPDATE (alterar algumas linhas existentes), INSERT (adicionar algumas novas linhas), DELETE (apagar algumas linhas). Há muitos outros verbos, mas esses são os que você vai usar mais, especialmente o SELECT.
Vamos imaginar uma tabela chamada athletes de atletas olímpicos com seis colunas:
nome
país
data de nascimento
altura
peso
sexo
Ao criar nossa tabela, também podemos especificar coisas como “país pode ficar vazio” ou “sexo deve ser M ou F”.
Consulta 1: Faça uma lista de todos os atletas em ordem alfabética. Isso mostrará a tabela inteira, ordenada por nomes de A a Z.
SELECT * FROM athletes ORDER BY name ASC
Consulta 2: Faça uma lista de todos os atletas na Equipe GB. Isso mostrará apenas as linhas dos atletas britânicos. Você não especificou como classificá-los, então não pode contar que eles voltem na ordem que deseja.
SELECT * FROM athletes WHERE country = 'Great Britain'
Consulta 3: Que país é mais pesado em média? Isso vai levar todas as linhas e colocá-las em grupos por país. Ele irá mostrar-lhe uma lista de nomes de países e o peso médio para cada grupo.
SELECT country,AVG(WEIGHT) FROM athletes GROUP BY country
Consulta 4: Qual mês de nascimento produz a maioria dos atletas olímpicos? Talvez você queira testar uma teoria astrológica sobre pessoas de leão serem grandes atletas. Isso mostrará quantos atletas olímpicos nasceram em cada mês.
SELECT MONTHNAME(birthdate),COUNT(*)~ FROM athletes GROUP BY MONTHNAME(birthdate)
Consulta 5: Acrescente um novo atleta à tabela. Para inserir uma linha, você pode especificar as colunas que você está adicionando (porque não precisa necessariamente adicionar todas elas o tempo todo) e o valor para cada uma.
INSERT
INTO athletes
(name,country,height,weight,gender)
VALUES ('Andrew Leimdorfer','Great Britain',180,74.8,'M')
Consulta 6: Obter todos os atletas do sexo masculino, na ordem da razão altura/peso. Talvez você possa notar algo estranho sobre o velocista canadense Ian Warner.
SELECT * FROM athletes WHERE gender = 'M' ORDER BY height/weight ASC
Consulta 7: Se você tem seus dados de london2012.com, você pensaria que o peso Ian Warner, de 5 ‘7 ” de altura, era de 160 kg, porque seu peso foi, provavelmente, inserido em libras em vez de kilogramas. Vamos corrigir através de um UPDATE em sua linha.
UPDATE athletes SET weight = weight/2.2 WHERE NAME = 'Ian Warner'
Consulta 8: Exclua todos os atletas americanos e canadenses, aqueles idiotas.
DELETE FROM athletes WHERE country = 'United States of America' OR country = 'Canada';
Uma vez que você tiver feito consultas suficientes, vai ver que uma consulta é como uma frase com uma gramática. Ela tem um “verbo” (que tipo de ação eu quero? ), um “objeto” (em quais tabelas quero executar a ação?), e “advérbios” opcionais (o quão específica eu quero que seja a ação?). Os “advérbios” incluem detalhes como “classificar por essa coluna” e “só faça isso para certas linhas”.
Nível Bônus: várias tabelas e um breve gosto de JOINs
Você provavelmente tem muito mais dados do que apenas atletas. Para cada país, você também pode ter a bandeira do país, sua população e a capital. Você também tem todos os eventos olímpicos, quais atletas participavam delas, em quais espaços eles estavam, qual a categoria do esporte a que pertencem. Para cada evento, você também tem os resultados: quem obteve quais medalhas e, em alguns casos, quais foram os tempos e os placares para cada caso.
A abordagem típica do Excel para isso seriam duas soluções muito loucas: ou você tem um monte de planilhas e meticulosamente referenciadas entre si, ou você tem um megaplanilha com todas as colunas (fontes de dados governamentais amam megaplanilhas).
Você pode ter uma planilha em que cada linha é um atleta, e então você tem uma longa lista de colunas, incluindo muita informação redundante e armazenada de jeito estranho, tal como:
nome, país, data de nascimento, altura, peso, sexo, populacao_do_pais, url_bandeira_pais , idh_pais, evento1, data_evento1, resultado_event1, data_evento2, resultado_evento2, data_evento3, resultado_event3, data_evento4, resultado_evento4, numero_de_medalhas
Essa abordagem de megaplanilha tem todos os tipos de deficiências:
- Você perde o benefício de navegar visualmente pela informação se a tabela ficar muito grande. Fica uma bagunça.
- Essa estrutura é muito rígida. A lei das megaplanilhas afirma que uma vez que você definir arbitrariamente “n” colunas como o número máximo de instâncias de uma linha, alguma linha irá precisar de n+1.
- Não há senso de relacionamento. Atletas são uma unidade atômica aqui, mas há outras. Você tem países, tem eventos (que pertencem ao esporte), tem resultados (que pertencem a eventos), tem atletas (que competem em eventos, temos resultados nesses eventos e quase sempre pertencem a países). Essas relações provavelmente serão a base para muitas histórias interessantes em seus dados, e a megaplanilha faz um mau trabalho de contabilizá-los.
- A análise é difícil. Como você encontra todos os atletas dos 100m rasos masculino? Alguns deles podem ter seu tempo em resultado_evento1, alguns poderiam tê-lo em resultado_evento2. Divirta-se com esses comandos IF() aninhados! E se algum desses dados forem inseridos manualmente, há uma boa chance de que você vai ter inconsistências textuais entre coisas como “100m dos homens”, “100 metros masculino”, e “100m”.
O SQL permite que você mantenha essas coisas em um monte de tabelas separadas, mas use conexões lógicas entre elas para calmamente tratá-las bem como um grande conjunto de dados. Para combinar tabelas como essas, você utiliza JOINS. Em uma única frase: um JOIN pega duas tabelas e as sobrepõe para conectar linhas de cada tabela em uma única linha. JOINS estão além do escopo deste artigo, mas elas são uma das coisas que fazem os bancos de dados excelentes, um breve exemplo está abaixo.
Você pode criar uma tabela para atletas com informações básicas, como altura e peso, uma tabela para eventos com detalhes sobre onde e quando eles aconteceram e qual é o recorde mundial atual, uma tabela para os países com informações sobre cada um deles e uma tabela para resultados, onde cada linha contém um atleta, um evento, seu resultado e qual medalha eles ganharam (se houver). Então você usa JOIN para combinar temporariamente várias tabelas em uma única consulta.
Quem ganhou medalhas de ouro hoje?
SELECT athletes.name, athletes.country, event.name FROM athletes, results, events WHERE athletes.id = results.athlete_id AND event.id = results.event_id AND event.date = DATE(NOW()) AND results.medal = 'Gold'
Quantas medalhas cada país tem?
SELECT
countries.name, COUNT(*)
FROM athletes, countries, results, events
WHERE athletes.id = results.athlete_id AND event.id = results.event_id AND athletes.country_id = countries.id
AND results.medal IN ('Gold','Silver','Bronze')
GROUP BY countries.id
***
Artigo escrito por Noah Veltman, desenvolvedor e jornalista na equipe de jornalismo visual da BBC. Publicado originalmente no portal Escola de Dados – http://schoolofdata.org/2013/11/07/sql-databases-vs-excel/
De 0 a 10, o quanto você recomendaria este artigo para um amigo?