Explicar
Distinguir dado, banco de dados, SGBD, esquema, instância e os problemas de planilhas ou arquivos isolados.
Disciplina de graduação · guia de aula
Banco de
Dados I.
Da pergunta de negócio ao modelo, do modelo às tabelas, das tabelas às consultas. Um roteiro para aprender fazendo e compreender por que cada decisão de projeto importa.
16 encontros sugeridos01 caso contínuo03 práticas interativas
01 / ENTENDERProblema
↓02 / REPRESENTARModelo
↓03 / IMPLEMENTARTabelas + SQL
↓04 / VERIFICARResposta confiável
01 / VISÃO GERAL
O que o estudante deverá conseguir fazer.
Este plano é uma proposta didática para uma disciplina introdutória. Ajuste carga horária, ferramenta, profundidade e avaliação à ementa da instituição.
Modelar
Traduzir regras de negócio em entidades, atributos, relacionamentos, cardinalidade e chaves.
Implementar
Criar tabelas relacionadas, restrições e operações básicas de inserção, atualização e exclusão.
Consultar
Escrever consultas SQL, interpretar resultados, testar casos limites e justificar escolhas de projeto.
Método de aula
Comece por uma pergunta real, construa o modelo com a turma, implemente uma versão pequena, provoque erros e peça que os estudantes expliquem o resultado. Conceitos entram para resolver problemas observados no laboratório.
02 / CONTEXTO HISTÓRICO
Como chegamos às tabelas relacionadas.
O banco relacional é uma resposta histórica ao problema de organizar e consultar dados sem prender cada pergunta à forma física de armazenamento.
Arquivos e estruturas navegacionais
Organizações usavam arquivos e modelos hierárquicos ou em rede. Consultas dependiam fortemente dos caminhos de acesso definidos pela aplicação.
Edgar F. Codd
O artigo A Relational Model of Data for Large Shared Data Banks ↗ propõe representar dados por relações e separa a visão lógica da organização física.
SQL e modelo ER
Pesquisas da IBM (International Business Machines) desenvolvem a linguagem que se tornaria SQL (Structured Query Language, ou linguagem de consulta estruturada). Em 1976, Peter Chen publica o modelo entidade relacionamento (ER) ↗ como ferramenta de representação conceitual.
Adoção e novos contextos
Sistemas de Gerenciamento de Bancos de Dados (SGBDs) relacionais se difundem em sistemas empresariais. Dados distribuídos, nuvem e outros modelos ampliam as opções, mas chaves, integridade e consultas continuam essenciais.
03 / FUNDAMENTOS
Antes de escrever SQL, entenda o que está guardando.
Uma tabela útil começa com definições claras. A pergunta não é “qual comando uso?”, mas “que fato esta linha representa?”.
Conjunto organizado
Dados relacionados, mantidos para atender consultas e operações de um contexto. Exemplo: alunos, livros, exemplares e empréstimos de uma biblioteca.
O software que gerencia
Um Sistema de Gerenciamento de Banco de Dados (SGBD) controla armazenamento, consultas, acesso, concorrência e integridade. PostgreSQL é um exemplo.
Estrutura × estado
O esquema define tabelas, colunas e regras. A instância é o conjunto de linhas existente em um momento específico.
Teoria × implementação
Relação é um conceito do modelo relacional. Tabelas SQL o implementam com diferenças práticas, como possibilidade de valores nulos e linhas repetidas em resultados.
Identificar e conectar
A chave primária (PK, Primary Key) identifica cada linha. A chave estrangeira (FK, Foreign Key) aponta para uma linha em outra tabela e sustenta a integridade referencial.
Regras que o banco aplica
NOT NULL, UNIQUE, PRIMARY KEY, FOREIGN KEY e CHECK evitam estados inválidos; cada regra tem um propósito diferente.
Siglas para consultar durante a aula
- SQL
- Structured Query Language: linguagem usada para definir, consultar e alterar dados relacionais.
- ER
- Entidade relacionamento: modelo conceitual para representar entidades, atributos e relações.
- PK / FK
- Primary Key (chave primária) / Foreign Key (chave estrangeira).
- 1FN, 2FN, 3FN
- Primeira, segunda e terceira forma normal: critérios progressivos de organização das relações.
- CTE
- Common Table Expression: expressão de tabela comum, criada com
WITHpara nomear uma etapa da consulta. - ACID
- Atomicidade, consistência, isolamento e durabilidade: propriedades esperadas de transações.
- OLAP
- Online Analytical Processing: processamento analítico de dados, comum em cubos e análises multidimensionais.
- README
- Arquivo de apresentação de um projeto: explica objetivo, estrutura, como executar e decisões tomadas.
PARA DISCUTIR EM SALA
Se duas pessoas puderem editar uma planilha de empréstimos ao mesmo tempo, o que pode dar errado? Que regras deveriam existir mesmo se uma aplicação esquecesse de validá-las?
04 / MODELAGEM
Quatro entidades. Uma história coerente.
Caso fictício: uma biblioteca universitária precisa saber quem levou cada exemplar, qual título ele representa e quando deve ser devolvido.
ANTES DO DIAGRAMA
De onde vem um banco de dados no dia a dia?
Ele começa com uma necessidade: alguém precisa registrar fatos, executar um processo ou responder a perguntas de forma confiável. O cliente pode ser uma empresa, um setor ou a pessoa que usa o sistema. Antes de criar tabelas, converse com quem solicita, com quem lança os dados e com quem vai consultá-los.
No caso da biblioteca, a demanda poderia ser: “preciso saber quais exemplares estão disponíveis, quem está com cada exemplar e quais devoluções estão atrasadas”. Essa frase inicia a conversa; ainda não define sozinha as tabelas.
- Necessidade
- Requisitos
- Modelo conceitual
- Modelo lógico
- Modelo físico
- Validar e ajustar
Coleta de requisitos
Descubra o objetivo, as pessoas envolvidas, os dados de entrada, as consultas esperadas e as regras que o sistema precisa respeitar. Entrevistas, observação do trabalho, formulários existentes e exemplos reais ajudam a revelar o processo.
- Pergunte: quem cadastra o livro? Um título pode ter várias cópias? Um aluno pode ter dois empréstimos? Quando uma devolução conta como atrasada?
- Registre: regras de negócio, campos necessários, casos excepcionais, permissões de acesso e dúvidas ainda sem resposta.
- Valide: leia as regras de volta para o cliente e teste exemplos como “aluno sem empréstimo” e “exemplar já emprestado”.
Saída desta etapa Lista de requisitos e regras verificáveis; por exemplo, “cada empréstimo registra um aluno e um exemplar”. O prazo de devolução deve ser confirmado com a biblioteca, não presumido.
Modelagem conceitual
Represente os conceitos do negócio e como se relacionam, sem decidir ainda tipos de coluna, comandos SQL ou qual SGBD usar. Entidades são coisas relevantes para o contexto; atributos descrevem essas coisas; relacionamentos ligam as entidades.
- Exemplo: Aluno faz Empréstimo; Empréstimo envolve Exemplar; Exemplar é cópia física de Livro.
- Cardinalidade: um Livro pode ter muitos Exemplares. Um Exemplar pertence a um Livro. A participação pode ser opcional: um Aluno pode ainda não ter empréstimos.
- Converse com o cliente: o desenho representa o trabalho real? “Livro” e “Exemplar” são de fato coisas diferentes para essa biblioteca?
Saída desta etapa Diagrama entidade relacionamento (ER) e regras de negócio compreensíveis para pessoas da área.
Leia também: Modelagem relacional: uma visão geral ↗
Modelagem lógica
Transforme os conceitos em uma estrutura relacional, ainda independente de um produto específico. Defina relações, atributos, chaves primárias (PK), chaves estrangeiras (FK), obrigatoriedade, domínios gerais e dependências entre dados. Revise redundâncias com a normalização.
- Exemplo:
alunos(id_aluno, nome, email);livros(id_livro, titulo);exemplares(id_exemplar, id_livro, tombo);emprestimos(id_emprestimo, id_aluno, id_exemplar, data_emprestimo, data_devolucao). - Relacionamento:
id_livroemexemplareseid_alunoememprestimosrepresentam ligações entre as relações. - Confira: um dado pertence a qual entidade? Uma correção de e-mail exigiria alterar várias linhas?
Saída desta etapa Esquema lógico com chaves, relações e regras documentadas, pronto para orientar a implementação.
Leia também: Modelagem relacional: uma visão geral ↗
Modelagem física
Adapte o esquema lógico ao SGBD escolhido. Agora entram nomes e tipos concretos de colunas, CREATE TABLE, restrições, índices, formas de acesso e decisões de desempenho. O projeto também precisa considerar permissões, cópias de segurança e como alterações serão implantadas.
- Exemplo no PostgreSQL:
id_aluno BIGINT,data_emprestimo DATE,email VARCHAR(255),PRIMARY KEYeFOREIGN KEY. - Validação: tente cadastrar um empréstimo com aluno inexistente, consultar atrasos e inserir dois exemplares com o mesmo tombo.
- Limite importante: uma FK garante que o exemplar existe, mas não impede, sozinha, dois empréstimos abertos para ele.
Saída desta etapa Script SQL, banco criado e testes com dados de exemplo. A seção de SQL abaixo mostra como escrever e executar esses comandos.
Para escolher os tipos: Diferença entre os tipos de dados em bancos de dados ↗
Na prática, há idas e voltas. Se a biblioteca mudar uma regra ou um teste revelar uma lacuna, revise os requisitos e os modelos antes de seguir. A sequência organiza o raciocínio; não substitui a conversa com as pessoas que usam o sistema. Leia também a explicação da IBM sobre os três modelos ↗
Ferramenta online para praticar: Abrir o brModelo Web ↗. Desenhe o modelo conceitual da biblioteca, converta para o lógico e examine o SQL gerado; confira as regras com o cliente antes de aceitar o resultado.
Veja o esquema lógico simplificado da biblioteca
As caixas abaixo mostram como as entidades do exemplo se conectam por chaves e cardinalidades. Compare este desenho com as regras levantadas na primeira etapa.
ALUNOSid_aluno PKnomeemail UNIQUE
1 : N↔
EMPRÉSTIMOSid_emprestimo PKid_aluno FKid_exemplar FKdatas
N : 1↔
EXEMPLARESid_exemplar PKid_livro FKtombo UNIQUE
N : 1↔
LIVROSid_livro PKtituloautor
Traduza as regras antes de desenhar.
Nas caixas, PK significa chave primária; FK, chave estrangeira. 1:N indica um para muitos; N:N, muitos para muitos.
- Um aluno pode ter vários empréstimos ao longo do tempo; cada empréstimo pertence a um aluno.
- Um livro pode possuir vários exemplares físicos; cada exemplar pertence a um livro.
- Um exemplar pode aparecer em vários empréstimos ao longo do tempo; cada empréstimo registra um exemplar.
Questão importante: “um exemplar só pode estar em um empréstimo aberto por vez” é uma regra adicional. As chaves estrangeiras, sozinhas, não a garantem.
TESTE INTERATIVO · CARDINALIDADE
Um livro pode ter vários exemplares. Cada exemplar pertence a um livro. Qual é a cardinalidade?
Escolha uma opção para ver a explicação.
05 / NORMALIZAÇÃO
Evite repetir fatos sem perceber.
Normalizar ajuda a reduzir redundância e anomalias de atualização. O objetivo não é multiplicar tabelas sem motivo, mas guardar cada fato no lugar adequado.
emprestimo_id | aluno_nome | aluno_email | livro_titulo | tombo | data
Se Ana fizer dez empréstimos, seu nome e e-mail aparecerão dez vezes. Uma correção de e-mail precisa atingir todas as linhas.
alunos → empréstimos → exemplares → livros
O nome pertence ao aluno; o título, ao livro; o tombo, ao exemplar. O empréstimo guarda chaves e datas.
Uma lista numa célula
Primeira Forma Normal. No exemplo, a coluna telefones guarda valores que precisam ser tratados separadamente.
ANTES · alunos id | nome | telefones 1 | Ana | 1111, 2222
Crie uma linha para cada telefone, preservando a relação com o aluno.
DEPOIS · alunos id | nome 1 | Ana telefones_aluno aluno_id | telefone 1 | 1111 1 | 2222
Agora é possível buscar ou remover um telefone sem interpretar uma lista dentro da célula.
Dependência de parte da chave
Segunda Forma Normal. Considere (aluno_id, disciplina_id) como chave composta. O nome do aluno não depende do par inteiro.
ANTES · matriculas aluno_id | disciplina_id | aluno_nome | nota 1 | 10 | Ana | 8 1 | 20 | Ana | 9
Guarde aluno_nome uma vez em alunos; a nota continua ligada ao par.
DEPOIS · alunos id | nome 1 | Ana matriculas aluno_id | disciplina_id | nota 1 | 10 | 8 1 | 20 | 9
Uma mudança no nome de Ana exige uma única atualização.
Dependência indireta
Terceira Forma Normal. Cada empréstimo tem um exemplar; o título depende do livro associado ao exemplar, não do identificador do empréstimo.
ANTES · emprestimos id | exemplar_id | livro_titulo 1 | 101 | SQL em prática 2 | 101 | SQL em prática
Deixe o título em livros e conecte as tabelas por chaves.
DEPOIS · livros id | titulo 10 | SQL em prática exemplares id | livro_id 101 | 10 emprestimos id | exemplar_id 1 | 101 2 | 101
Corrigir o título do livro em um lugar evita versões conflitantes.
Estes exemplos simplificam as dependências para fins didáticos. A 2FN pressupõe 1FN; a 3FN pressupõe 2FN. Para avaliar uma tabela real, identifique as chaves candidatas e as dependências funcionais antes de decompor.
EXERCÍCIO DE DIAGNÓSTICO
Na tabela matriculas(aluno_id, disciplina_id, aluno_nome, disciplina_nome, nota), a chave é (aluno_id, disciplina_id). Quais atributos dependem apenas de parte da chave?
Ver raciocínio esperado
aluno_nome depende de aluno_id; disciplina_nome depende de disciplina_id. Crie alunos, disciplinas e matriculas para evitar repetição. A nota continua associada ao par aluno–disciplina.
06 / SQL DE VERDADE
Da estrutura à pergunta.
Os exemplos abaixo usam PostgreSQL. O script completo inclui as quatro tabelas, dados fictícios e desafios para executar em um banco de testes.
Cria ou modifica estruturas: CREATE TABLE, ALTER TABLE, DROP TABLE.
CREATE TABLE alunos (...);Insere, atualiza ou exclui registros: INSERT, UPDATE, DELETE.
UPDATE alunos SET nome = 'Ana' WHERE id_aluno = 1;Lê dados com SELECT, filtros, junções e agregações.
SELECT nome FROM alunos;Concede ou revoga permissões: GRANT e REVOKE. Execute com uma função autorizada.
GRANT SELECT ON alunos TO leitor;Controla a confirmação ou reversão de mudanças: BEGIN, COMMIT, ROLLBACK.
BEGIN; UPDATE ...; COMMIT;Essas categorias são uma convenção didática. Algumas referências incluem SELECT em DML em vez de separá-lo como DQL; BEGIN inicia a transação no PostgreSQL.
Crie uma estrutura com regra.
CREATE TABLE alunos (
id_aluno INTEGER PRIMARY KEY,
nome VARCHAR(120) NOT NULL,
email VARCHAR(255) NOT NULL UNIQUE
);PRIMARY KEY identifica; UNIQUE impede e-mails repetidos; NOT NULL exige valor.
Insira ou atualize fatos.
INSERT INTO alunos (id_aluno, nome, email)
VALUES (1, 'Ana Lima', 'ana@exemplo.edu');
UPDATE alunos
SET email = 'ana.novo@exemplo.edu'
WHERE id_aluno = 1;Antes de executar UPDATE ou DELETE, confira o filtro com um SELECT.
Encontre empréstimos abertos.
SELECT a.nome, l.titulo
FROM emprestimos AS e
JOIN alunos AS a ON a.id_aluno = e.id_aluno
JOIN exemplares AS x
ON x.id_exemplar = e.id_exemplar
JOIN livros AS l ON l.id_livro = x.id_livro
WHERE e.data_devolucao IS NULL;O JOIN reconecta fatos separados. IS NULL identifica empréstimos ainda sem data de devolução.
Conte empréstimos por aluno.
SELECT a.nome, COUNT(e.id_emprestimo) AS total
FROM alunos AS a
LEFT JOIN emprestimos AS e
ON e.id_aluno = a.id_aluno
GROUP BY a.id_aluno, a.nome
ORDER BY total DESC;LEFT JOIN preserva alunos sem empréstimo. Conte a chave da tabela associada para que eles apareçam com zero.
ALÉM DO SELECT
Transações agrupam mudanças relacionadas. BEGIN, COMMIT e ROLLBACK ajudam a tratar falhas; índices podem acelerar consultas, mas têm custo de armazenamento e escrita. Esses temas entram na parte final do curso.
07 / LABORATÓRIO INTERATIVO
Filtre, consulte e confira.
Esta demonstração roda no navegador com cinco registros fictícios. Ela simula o resultado de consultas SQL para ensinar filtro e junção; o arquivo para download permite executar SQL real no PostgreSQL.
| ID | Aluno | Título | Empréstimo | Situação |
|---|
Observe: “em aberto” significa data_devolucao IS NULL. Não é o mesmo que “atrasado”; para isso também precisaríamos comparar a data prevista com uma data de referência.
TESTE INTERATIVO · CONSULTA
Qual junção mantém alunos que nunca fizeram empréstimo?
Escolha uma opção para ver a explicação.
08 / PLANO DE ENSINO
16 encontros para conduzir a disciplina.
Sequência sugerida para um semestre. Cada encontro propõe uma pergunta, uma prática e uma evidência de aprendizagem. Abra os blocos em aula conforme a turma avançar.
UNIDADE 01 · BASES
Por que bancos de dados existem?
01 O problema dos arquivos isolados
Conceitos: dado, informação, persistência, redundância, inconsistência e compartilhamento. Em aula: peça a duas equipes que atualizem cópias de uma planilha de empréstimos; compare resultados. Entrega: lista de problemas e regras necessárias.
02 SGBD, esquema e arquitetura básica
Conceitos: banco × SGBD, esquema × instância, três níveis de abstração, independência lógica e física. Em aula: identifique aplicação, SGBD e banco no sistema da biblioteca. Entrega: mapa simples de responsabilidades.
03 Origem do modelo relacional
Conceitos: relações, tuplas, atributos, domínio, Codd (1970) e diferença entre relação teórica e tabela SQL. Em aula: compare uma planilha com duas tabelas relacionadas. Entrega: glossário comentado.
04 Regras de negócio e levantamento de requisitos
Conceitos: perguntas de negócio, entidades candidatas, regras verificáveis e casos limites. Em aula: entrevistar um “bibliotecário” representado pelo professor. Entrega: cinco regras de negócio numeradas.
UNIDADE 02 · MODELAGEM
Do cenário ao esquema.
05 Modelo entidade relacionamento
Conceitos: entidade, atributo, identificador e relacionamento; Chen (1976). Em aula: desenhe alunos, livros, exemplares e empréstimos. Entrega: primeiro diagrama ER.
06 Cardinalidade, participação e casos limites
Conceitos: 1:1, 1:N, N:N, obrigatoriedade e opcionalidade. Em aula: teste o modelo com “aluno sem empréstimo” e “livro com três exemplares”. Entrega: diagrama revisado e justificativa.
07 Transformação para o modelo relacional
Conceitos: tabelas, chaves primárias e estrangeiras, relacionamentos N:N com tabela associativa. Em aula: converta o ER da biblioteca em relações. Entrega: esquema lógico com chaves primárias (PK) e estrangeiras (FK).
08 Dependências funcionais e normalização
Conceitos: anomalias, 1FN, 2FN e 3FN com limites e critérios. Em aula: corrija a tabela de matrículas apresentada nesta página. Entrega: esquema normalizado e explicação do que mudou.
UNIDADE 03 · SQL
Construa, consulte e altere.
09 Ambiente, tipos e CREATE TABLE
Conceitos: PostgreSQL, tipos simples, DDL, PK, FK, UNIQUE, NOT NULL e CHECK. Em aula: execute o script desta página em banco de testes. Entrega: tabelas criadas e capturas do esquema.
10 INSERT, UPDATE, DELETE e filtros
Conceitos: DML, SELECT, WHERE, ORDER BY, operadores e NULL. Em aula: inserir um aluno, atualizar e consultar antes de excluir. Entrega: consultas com resultados esperados.
11 JOIN e integridade referencial
Conceitos: INNER JOIN, LEFT JOIN e comportamento de FKs. Em aula: listar empréstimos com aluno e título; testar aluno sem empréstimo. Entrega: duas consultas com explicação da diferença.
12 Agregação, GROUP BY e HAVING
Conceitos: COUNT, SUM, agrupamento e filtro de grupos. Em aula: conte empréstimos por aluno e títulos com mais de um exemplar. Entrega: relatório SQL pequeno.
UNIDADE 04 · CONFIABILIDADE
Verifique o que acontece em uso real.
13 Subconsultas, CTE (expressão de tabela comum) e leitura de consultas
Conceitos: decompor perguntas e nomear etapas com WITH. Em aula: localizar alunos com total de empréstimos acima da média. Entrega: consulta comentada e teste de borda.
14 Transações e concorrência: primeira visão
Conceitos: ACID (atomicidade, consistência, isolamento e durabilidade), BEGIN, COMMIT e ROLLBACK. Em aula: simule uma devolução e desfaça uma alteração de teste. Entrega: relato do estado antes/depois.
15 Índices, segurança e limites do modelo
Conceitos: índice e custo de manutenção, permissões, cópia de segurança, qualidade de dados. Em aula: discuta o controle de “um empréstimo aberto por exemplar”. Entrega: plano de melhorias priorizado.
16 Projeto integrador e apresentação
Em aula: apresente requisitos, ER, esquema relacional, script de criação, consultas e testes. Entrega: repositório ou pacote com diagrama, SQL executável, dados de teste e README com decisões de projeto.
09 / AVALIAÇÃO SUGERIDA
Peça evidências, não apenas comandos.
Uma rubrica possível para o projeto integrador. Adapte pesos e critérios à política da disciplina.
30%Requisitos e modelagem
Regras explícitas, diagrama coerente, cardinalidades e transformação justificadas.
25%Integridade e normalização
Chaves, restrições, redução de redundância e explicação de limites.
30%SQL e testes
Script reproduzível, consultas corretas, casos vazios e testes de falha.
15%Comunicação
README, nomenclatura, comentários e apresentação das decisões.
DESAFIO FINAL PARA A TURMA
Acrescente reservas de livros ao sistema. Pode haver mais de uma reserva para o mesmo título? A reserva é do livro ou do exemplar? Quais regras precisam ser esclarecidas antes de criar tabelas?
Ver orientação para discussão
Não há resposta única sem regras de negócio. Peça que a equipe declare suposições, modele pelo menos dois cenários, escolha um deles e explique impactos em cardinalidade, chaves, concorrência e consultas.
10 / MATERIAIS DO SITE
Continue praticando sem sair do acervo.
Use estes materiais como atividades de apoio, reforço ou ponte para disciplinas posteriores.
PRÁTICASQL Builder InterativoMonte SELECTs, filtros, JOINs e agregações. ↗PRÓXIMO PASSOData Warehouse e Cubos OLAP (análise multidimensional)Veja como a modelagem muda para análise. ↗LABORATÓRIOData Quality LabEncontre nulos, duplicidades e inconsistências. ↗CONSULTAGlossário de Dados e IAReforce termos essenciais durante as aulas. ↗CONTEXTOGovernança e QualidadeConecte as regras técnicas à confiança nos dados. ↗TRILHASQL e ModelagemEncontre outros exercícios e materiais complementares. ↗
11 / BIBLIOGRAFIA E FONTES
Livros que sustentam a disciplina.
As datas identificam as edições indicadas, não o nascimento de cada conceito. Prefira a edição disponível na biblioteca da instituição e confirme capítulos conforme a versão usada.
Database System Concepts
Abraham Silberschatz, Henry F. Korth e S. Sudarshan. McGraw-Hill. Visão ampla: modelo relacional, SQL, projeto, armazenamento e transações.
Site oficial do livro ↗Fundamentals of Database Systems
Ramez Elmasri e Shamkant B. Navathe. Pearson. Forte apoio para modelagem ER, projeto lógico e fundamentos de implementação.
Página da editora ↗Database Systems: The Complete Book
Hector Garcia-Molina, Jeffrey D. Ullman e Jennifer Widom. Pearson. Referência adicional para linguagem de consulta, projeto e funcionamento de SGBDs.
Página da editora ↗Database Design and Relational Theory
C. J. Date. Apress. Leitura para aprofundar dependências, formas normais, redundância e rigor do projeto relacional.
Ficha do livro ↗1970 · EDGAR F. CODDArtigo original do modelo relacional ↗1976 · PETER CHENArtigo original do modelo entidade relacionamento ↗DOCUMENTAÇÃOTutorial oficial do PostgreSQL ↗DOCUMENTAÇÃORestrições e integridade no PostgreSQL ↗
LEITURAS DE AMPLIAÇÃO
Depois dos fundamentos: dados em uso nas organizações
Esses textos levam a conversa além do projeto relacional introdutório. Use-os para discutir arquitetura e valor dos dados, sem confundir esses temas com os objetivos básicos de Banco de Dados I.
12 / REFERÊNCIA EM VÍDEOReveja, pause,
Playlist indicada para Banco de Dados IABRIR NO YOUTUBE ↗Reveja, pause,
coloque em prática.
Playlist complementar indicada para a disciplina. Use os vídeos ao lado dos exercícios, mantendo os livros e a documentação como base de conferência.