IBD014 • Estudo Offline Completo
Este material foi estruturado para você estudar sozinho, com progressão didática, exemplos reais, exemplos técnicos e exercícios resolvidos. O foco está no conteúdo já estudado em sala (Aulas 1 a 7).
Um banco de dados é uma coleção organizada de dados relacionados, armazenados de forma estruturada, com regras de integridade e acesso controlado por um SGBD.
Pense em uma empresa com vendas, estoque e financeiro. Se cada setor salva dados em planilhas próprias, a empresa perde controle. Banco de dados existe para centralizar a informação e reduzir conflitos.
O cliente muda de endereço. Com arquivos separados, Vendas atualiza e Financeiro não. Resultado: boletos enviados para endereço antigo.
Cliente(id_cliente, nome, endereco)
Pedido(id_pedido, data, id_cliente)
Regra: Pedido.id_cliente referencia Cliente.id_cliente.Erro comum: confundir banco de dados com sistema/aplicação.
Evite isso lembrando: banco guarda e organiza dados; aplicação usa os dados para atender o usuário.
Exercício: Explique por que redundância gera inconsistência.
Exemplo resolvido: cadastro de cliente duplicado em dois setores, apenas um atualizado.
Heuser (Projeto de Banco de Dados): o ponto de partida do projeto não é a tabela, é o entendimento do universo de informação e das regras de negócio. A modelagem conceitual existe para representar significado antes de implementação.
Elmasri e Navathe: dados integrados reduzem redundância e anomalias porque a organização passa a ter um esquema unificado e controlado, com restrições explícitas de integridade.
Korth e Silberschatz: um SGBD agrega vantagens de consistência, controle de concorrência e segurança, pontos que não são bem resolvidos na abordagem baseada em arquivos isolados.
Date: a qualidade conceitual do banco define a qualidade lógica e física posteriores. Em outras palavras, erro de conceito no início custa caro no fim.
Modelos de dados são formas de representar a realidade informacional. Eles evoluíram conforme as demandas de flexibilidade, escala e independência entre dado e aplicação.
Quanto mais rígido o modelo, mais difícil adaptar o sistema a novas regras de negócio. A evolução dos modelos foi uma resposta a esse problema.
Uma instituição que antes registrava apenas alunos passa a registrar também cursos híbridos, trilhas e turmas compartilhadas. Um modelo rígido não acompanha essa mudança.
Erro comum: achar que modelo relacional “substituiu” todos os outros.
Evite absolutismo: cada modelo responde melhor a certos tipos de problema.
Exercício: Qual modelo domina aplicações corporativas tradicionais e por quê?
Como pensar na prova: relacione evolução tecnológica com necessidade de negócio.
Korth e Silberschatz: descrevem a evolução dos modelos como resposta a limitações práticas: dificuldade de manutenção, baixa independência de dados e acoplamento entre aplicação e armazenamento.
Date: mostra que o sucesso do modelo relacional não é só histórico, é formal: o modelo possui base matemática e lógica rigorosa para representar e manipular dados com precisão.
Elmasri e Navathe: reforçam que a escolha de modelo depende de requisitos de representação e operação, mas o relacional se consolidou por equilíbrio entre clareza, poder de consulta e suporte de ferramentas.
Projeto de banco é o processo de transformar necessidades informacionais do domínio em estruturas consistentes de dados. UoD (Universe of Discourse) é o recorte do mundo que será modelado.
Se você não define o que está dentro e fora do escopo, modela tudo ao mesmo tempo e o diagrama vira um “mapa confuso”. UoD evita isso.
Em uma clínica, o UoD pode incluir pacientes, médicos, consultas e exames. Pode deixar fora, por exemplo, folha de pagamento.
Ciclo de vida simplificado:
1) Levantamento de requisitos
2) Modelo conceitual
3) Modelo lógico
4) Modelo físico
5) Implementação e validaçãoErro comum: começar direto pela tabela sem consolidar requisitos.
Evite isso criando lista de regras do negócio antes de desenhar entidades.
Exercício: Defina UoD para um sistema de biblioteca.
Ponto-chave: projeto bom começa com escopo claro, não com SQL.
Heuser: organiza o projeto de banco como processo incremental: requisitos -> modelo conceitual -> modelo lógico -> implementação. A recomendação é evitar salto direto para código.
Elmasri e Navathe: tratam o levantamento de requisitos como etapa crítica, pois entidades, atributos e relacionamentos só fazem sentido quando ancorados em regras reais do domínio.
Korth e Silberschatz: destacam que qualidade de projeto reduz retrabalho e melhora desempenho global de manutenção do sistema.
Date: enfatiza que abstração bem construída preserva independência entre níveis, facilitando evolução futura sem quebrar toda a aplicação.
Modelo conceitual representa significado do domínio; modelo lógico traduz para estrutura relacional; modelo físico define implementação no SGBD.
Conceitual responde “o que existe”; lógico responde “como organizar”; físico responde “como armazenar e otimizar”.
Uma faculdade precisa registrar alunos e disciplinas. No conceitual, você define entidades. No lógico, cria tabelas. No físico, decide tipos, índices e constraints.
Erro comum: misturar decisões físicas no modelo conceitual.
No conceitual, evite detalhes como VARCHAR(120) e índices.
Exercício: Classifique cada item como conceitual, lógico ou físico.
Como pensar na prova: identifique primeiro o nível de abstração pedido no enunciado.
Date: independência de dados é princípio central do projeto de bancos. Separar níveis não é formalismo; é mecanismo para reduzir impacto de mudanças.
Korth e Silberschatz: a arquitetura em níveis melhora administração, portabilidade e manutenção, porque decisões físicas podem evoluir sem reescrever toda regra de negócio.
Heuser: no ensino de modelagem, a distinção entre níveis evita confusão didática e melhora consistência do desenho.
Elmasri e Navathe: reforçam que o modelo conceitual deve representar semântica do domínio de forma independente de SGBD específico.
O MER (Modelo Entidade-Relacionamento) descreve dados e vínculos do domínio; o DER é sua representação gráfica.
Antes de criar tabelas, você precisa enxergar “quem se relaciona com quem” e com qual obrigatoriedade.
Em seguradora: cliente possui apólice; apólice cobre carro; carro pode participar de acidentes.
Cardinalidade:
1:1 -> um para um
1:N -> um para muitos
N:N -> muitos para muitosErro comum: definir cardinalidade apenas pela intuição e não pelas regras de negócio.
Evite isso transformando frases do requisito em perguntas: “é obrigatório?”, “quantos no máximo?”.
Exercício: “Um aluno pode cursar várias disciplinas e cada disciplina tem vários alunos.”
Exemplo resolvido: N:N no conceitual não fica direto no relacional; precisa de tabela intermediária.
Elmasri e Navathe: detalham estrutura do MER com precisão: tipos de atributo, participação, cardinalidade e restrições. Essa base ajuda a justificar o desenho, não apenas desenhar.
Heuser: oferece método muito prático para transformar enunciado textual em DER, perguntando "quem são as entidades?", "quais atributos as descrevem?" e "como elas se relacionam?".
Date: apesar de foco relacional, contribui para rigor conceitual ao defender modelagem sem ambiguidades semânticas.
Korth e Silberschatz: conectam modelagem com implementação, mostrando como decisões de relacionamento impactam consultas e integridade.
Entidade forte possui chave própria. Entidade fraca depende de outra entidade para identificação completa. Autorrelacionamento ocorre quando a entidade se relaciona com ela mesma.
Nem todo elemento do domínio “vive sozinho”. Alguns só existem vinculados a outro, como item de pedido.
Pedido e ItemPedido: item sem pedido não faz sentido. Em organograma, um funcionário pode supervisionar outro.
Entidade forte: Pedido(id_pedido)
Entidade fraca: ItemPedido(id_pedido, numero_item)
Autorrelacionamento:
Funcionario(id_funcionario, id_supervisor)Erro comum: criar PK artificial na entidade fraca sem preservar dependência com a entidade forte.
Evite isso mantendo a FK da entidade forte dentro da chave da entidade fraca quando necessário.
Exercício: Classifique “Dependente” em sistema de RH (depende de funcionário titular).
Como pensar na prova: pergunte “essa entidade existe sem a outra?”
Elmasri e Navathe: formalizam entidade fraca como aquela cuja identificação depende de entidade proprietária e de relacionamento identificador.
Heuser: destaca que, em modelagem didática, a principal pergunta para diferenciar forte e fraca é: "há identificação autônoma no domínio?"
Korth e Silberschatz: mostram que esse cuidado conceitual evita inconsistências no mapeamento para o modelo lógico.
Date: reforça que identidade e dependência devem ser tratadas com precisão semântica para preservar coerência relacional.
Generalização agrupa entidades específicas em uma superclasse; especialização cria subclasses a partir de uma entidade mais geral. As subclasses herdam atributos e relacionamentos da superclasse.
Quando vários tipos compartilham informações, duplicar campos em todas as entidades gera manutenção ruim. Herança conceitual organiza isso.
Em instituição de ensino: Pessoa pode ser Aluno, Professor e Funcionário. Todos têm nome e CPF; cada subclasse tem atributos próprios.
Classificações:
Total (t): toda instância da superclasse pertence a alguma subclasse
Parcial (p): pode existir instância só na superclasse
Exclusiva (x): instância pertence a apenas uma subclasse
Compartilhada (c): instância pode pertencer a mais de umaErro comum: confundir “total/parcial” com “exclusiva/compartilhada”.
Total/parcial trata cobertura da superclasse; exclusiva/compartilhada trata sobreposição entre subclasses.
Exercício: “Todo veículo cadastrado é ou Carro ou Moto, nunca os dois.”
Ponto-chave: responda sempre em duas dimensões: cobertura e sobreposição.
Heuser: apresenta generalização/especialização como extensão importante do MER para evitar repetição de atributos e representar hierarquias reais do domínio.
Elmasri e Navathe: tratam formalmente as restrições de especialização (disjunção/sobreposição e total/parcial), fundamentais para leitura correta de enunciados de prova.
Date: ajuda a avaliar impactos no modelo relacional, principalmente quando diferentes estratégias de implementação alteram redundância e custo de junção.
Korth e Silberschatz: reforçam a análise de trade-off: simplicidade de consulta versus normalização e clareza semântica.
Para aprofundar com método, use este mapa: cada autor contribui com uma lente específica de estudo.
Melhor referência para processo de modelagem: levantamento de requisitos, construção do MER/DER e transição para estruturas implementáveis.
Use este livro quando o desafio for "como sair do enunciado e chegar ao diagrama correto".
Melhor referência para fundamentação conceitual formal de entidades, relacionamentos, restrições estruturais e extensões do modelo.
Use quando precisar justificar tecnicamente cardinalidades e tipos de participação.
Melhor referência para visão de sistema: papel do SGBD, arquitetura, evolução dos modelos e integração com aplicações.
Use para responder perguntas sobre benefícios, segurança, concorrência e administração.
Melhor referência para raciocínio formal e precisão conceitual. Ajuda a evitar respostas vagas em prova.
Use para consolidar termos e argumentos com rigor lógico.
Este bloco está organizado por aula. Cada questão traz tipo, dificuldade, gabarito, justificativa e erro comum associado.
O P1, neste momento, concentra os temas de Conceitos até Generalização/Especialização. Próximos tópicos (normalização, SQL e álgebra relacional) ficam para a etapa seguinte da disciplina.