Banco de dados I - conceitos básicos
•Transferir como PPTX, PDF•
0 gostou•1,231 visualizações
O documento discute conceitos básicos de modelagem de dados em banco de dados, incluindo: 1) Atributos, tuplas, chaves primárias e estrangeiras; 2) Relacionamentos entre entidades como 1:1, 1:N e N:N; 3) Conjuntos fracos, auto-relacionamentos e grau de relacionamentos.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Banco de dados I - conceitos básicos
Semelhante a Banco de dados I - conceitos básicos (20)
Mais de Rodrigo Kiyoshi Saito
Mais de Rodrigo Kiyoshi Saito (20)
Último
Último (20)
Banco de dados I - conceitos básicos
- 1. Rodrigo Kiyoshi Saito / rodrigok@anchieta.br BANCO DE DADOS I
- 2. Tópicos abordados • Atributos • Tuplas • Chave primária e estrangeira • Convenção para utilização em diagramas • Relacionamentos
- 3. Tópicos abordados • Entidades fracas • Auto-relacionamentos • Agregações • Especificação • Integridade referencial
- 4. Atributos • Os atributos são informações básicas que qualificam uma entidade e descrevem seus elementos ou características. • Quando transpostos ao modelo físico (ao banco de dados), chamamos os atributos de campos ou colunas. • Note que todas as entidades devem possuir os atributos necessários ao andamento das operações da empresa, do contrário a entidade não será necessária para o sistema.
- 5. Atributos • Esses atributos devem representar o objeto na sua totalidade. • Há uma tendência a confundir Entidade e Atributo. • Tenha sempre em mente que um Atributo é uma característica, logo não contém um grupo de informações. • Por sua vez, uma Entidade sempre é um grupo.
- 6. Atributos • No mínimo são necessários dois atributos para criar uma entidade. • Uma entidade com um único atributo normalmente será agregada a outra entidade existente ao modelo.
- 7. Exemplos de Atributos Exemplos de atributos as entidades: - Entidade Pessoa: nome, endereço, documento, data de nascimento, telefone, e-mail; - Entidade Nota Fiscal: série, número, data e emissão e cliente;
- 8. Exemplos de Atributos COD. NOME DO CD NOME DA MUSICA NOME DO AUTOR 01 Mais do Mesmo Será Renato Russo e ... 01 Mais do Mesmo Ainda é Cedo Renato Russo e ... 01 Mais do Mesmo Tempo Perdido Renato Russo 02 Bate-Boca Meninos, Eu vi Tom Jobim e ... 02 Bate-Boca Eu te amo Tom Jobim e ... CHAVE PRIMARIA ATRIBUTOS TUPLA
- 9. Atributos Um atributo chave é um dos atributos de um CE especialmente projetado para identificar de forma única qualquer entidade do CE. É importante enfatizar a expressão acima especialmente projetado, porque a unicidade do valor do atributo determinante deve ser garantida para qualquer conteúdo futuro do CE e não apenas para a instancia atual do CE.
- 10. Exemplo de representação dos atributos Funcionário (numf, RG, CPF, nome, end, salário) funcionário RG CPF nomenumf end salário
- 11. Tupla • É uma estrutura de atributos intimamente relacionados e interdependentes que residem em uma entidade. • Quando transposta ao modelo físico, uma tupla equivale a um registro ou linha da tabela.
- 12. Chave • É um atributos utilizado para indexar dados. • Há três tipos de chaves: – Primária – Estrangeira; – Secundária;
- 13. Chave primária • É o atributo que permite identificar uma única ocorrência de uma tupla em uma Entidade. • Dessa forma, seu conteúdo deve ser único, exclusivo e imutável para cada linha dessa Entidade. Todos os demais atributos da entidade devem depender unicamente desse atributo. • Caso não exista um atributo que possa assumir a posição de chave primária, é preciso cria-lo. Veja que nem todos campos é uma boa chave.
- 14. Chave primária • Eventualmente uma chave primária pode conter mais de um atributo. • Nesse caso, a chave conterá mais de um atributo, mas será considerada a chave da tabela. • A união dos dois atributos é que deve garantir o acesso a uma única linha da entidade. • Esse caso de chave primária é chamado de Chave Concatenada ou Chave Composta;
- 15. Chave estrangeira • É o atributo que estabelece a relação de uma Entidade com a Chave Primária de outra Entidade e permite uma relação entre entidades. • Isto ocorre quando uma Entidade dependente herda a chave da Entidade Fundamental exatamente para estabelecer o relacionamento entre elas.
- 16. Chave estrangeira 01 Mais do Mesmo 02 Bate-Boca 01 Será 01 02 Ainda é Cedo 01 03 Tempo Perdido 01 04 Meninos, Eu vi 02 05 Eu te amo 02 ENTIDADE CD CHAVE PRIMÁRIA ENTIDADE MÚSICA CHAVE PRIMÁRIA ENTIDADE MÚSICA CHAVE ESTRANGEIRA
- 17. Chave Secundária • Esta chave é utilizada como meio de classificação e pesquisas em entidades. • Sempre que houver a necessidade de buscar informações semelhantes, em ordem crescente ou decrescente, em função de datas, valores ou status predefinidos, criam-se chaves secundárias. • Podem também ser concatenadas a outras chaves secundárias para extrair a informação desejada.
- 18. Tipos de Atributos • Um atributo pode conter vários subatributos. Nesse caso ele se diz itens de grupo ou composto. Por exemplo: Atributo: endereço Subatributos: Local(Rua, Número, Complemento), Cidade, CEP.
- 19. Tipos de Atributos • A representação gráfica desse atributo composto é: end númerorua local complemento cidade CEP
- 20. Tipos de Atributos Transformação em tabela: • endereco(rua, número, complemento, cidade, cep)
- 21. Tipos de Atributos • Se um atributo de uma entidade pode tomar diversos valores então se diz multivalorado. Por exemplo: Atributo: Telefone Valores: (11) 4521-8444 (11) 4588-8754
- 22. Tipos de Atributos • Essa propriedade pode ser indicada colocando-se um * após o nome do atributo multivalorado. Funcionário (numf, nome, telefone*)
- 23. Para identificar as entidades, tente seguir os passos a seguir • 1 – Examine os substantivos. Eles são objetos com significa próprio; • 2 – Dê um nome a cada Entidade; • 3 – Há informações relevante a respeito da entidade necessária às operações da empresa? • 4 – Cada instância da entidade possui um identificador único (chave)?
- 24. Para identificar as entidades, tente seguir os passos a seguir • 5 – Escreva uma descrição da suposta Entidade (CD é o produto básico de venda da empresa. Exemplos cd CDs são: Mais do Mesmo e Bate Boca); • 6 – Faça um diagrama com, pelo menos, alguns de seus atributos;
- 25. Relacionamentos • Sempre que duas entidades apresentarem interdependência (por exemplo, autor da música ou música do CD), indica-se um relacionamento entre elas. • Deve-se perguntar a cada par de entidades se elas se relacionam.
- 26. Relacionamentos • Cada entidade 1 {deve ter ou pode ter} relacionamento {uma ou mais ou uma única} entidade2;
- 27. Relacionamentos • Assim, podemos dizer que: 1 – Cada CD deve ser gravado por uma única gravadora; 2 – Cada gravadora pode ter gravado um ou mais CDs; 1 – Cada autor pode ter escrito uma ou mais músicas; 2 – Cada música pode ser escrita por um ou mais autores; 1 – Cada música pode estar gravada em um ou mais CDs. 2 – Cada CD deve conter uma ou mais músicas.
- 28. Relacionamentos • Conforme você pode notar, cada relacionamento contém um nome (normalmente um verbo como ser gravado, conter, ter escrito), a determinação de opcionalidade (deve ou pode) e um grau ou cardinalidade (uma única ou uma ou mais).
- 29. Análise dos tipos de Relacionamentos • Há três tipos de relacionamentos (também muito conhecido como CARDINALIDADE): - Um para um (1:1); - Um para Muitos (1:N); - ou muitos para muitos (N:N);
- 30. Relacionamento 1:1 • Ocorre sempre que uma entidade tiver uma única ocorrência para cada ocorrência na outra entidade. • Sempre que houver esse relacionamento, deve-se perguntar se realmente são duas entidades distintas ou se elas podem ser unidas.
- 31. Relacionamento 1:1 • Normalmente, ao checarmos a chave de ambas as entidades, chegamos facilmente à conclusão se as entidades devem ou não ser unidas. • Da mesma forma, deve-se perguntar se esse relacionamento sempre será um para um ou se existe a possibilidade de, amanhã, vir a ser um para muitos.
- 32. Exemplo de Relacionamento 1:1 DEPARTAMENTO GERENTE 1 1 PLACA-MÃE COMPUTADOR 1 1
- 33. Exemplo de Relacionamento 1:1 • se uma entidade de um CE só pode estar associada a uma única entidade de outro CE e vice-versa, dizemos então que o relacionamento é de cardinalidade 1 para 1 ou 1:1.
- 34. Exemplo de Relacionamento 1:1 FUNCIONÁRIOS DEPARTAMENTO 1 1
- 35. Relacionamento 1:N (ou N:1) • Ocorre sempre que uma entidade se relacionar com uma ou mais tuplas da outra entidade e esta outra se relacionar apenas com uma tupla daquela entidade. • Esse relacionamento é mais comum e fácil de ser analisado. Nesse caso, a parte onde o relacionamento é 1 contém os dados básicos da entidade (pois é a chave primária dessa entidade) e o lado muitos fará parte da lista de atributos não chave.
- 36. Exemplo de Relacionamento 1:N (ou N:1) GRAVADORA CD 1 N CLIENTE PEDIDO 1 N
- 37. Exemplo de Relacionamento 1:N (ou N:1) PEDIDO ITEM_DO_PEDIDO 1 N FUNCIONÁRIO DEPARTAMENTOLOTAR 1N
- 38. Relacionamento N:N (ou N:M) • Ocorre sempre que uma entidade se relacionar com várias tuplas de outra entidade e esta, por sua vez, relacionar-se com várias tuplas daquela entidade. • Esse relacionamento somente é possível na modelagem lógica de dados, uma vez que não se consegue implanta-lo em banco de dados relacionais.
- 39. Relacionamento N:N (ou N:M) • Ele será transformado em dois relacionamentos: um para muitos (1:n) e uma Entidade Associativa Atributiva será identificada, caso haja outras informações que devam ser agregadas a esta nova entidade
- 40. Exemplos de Relacionamento N:N (ou N:M) AUTOR LIVROESCREVER N N ALUNO DISCIPLINAESTUDAR N N
- 41. Exemplos de Relacionamento N:N (ou N:M) PRODUTO FORNECEDORFORNECER N N FNCIONÁRIO PROJETOPARTICIPA N N
- 42. Relacionamento N:N (ou N:M) • A transformação à qual nos referimos fera com que para cada um dos relacionamentos anteriores seja criado um item que terá o relacionamento um para muitos (1:n), com cada uma das outras entidades. • As novas entidades criadas serão formadas pela união das chaves primárias das entidades e, eventualmente, por novos atributos necessários. • Não esqueça que casos novos atributos sejam identificados na entidade associativa, esta será considerada atributiva.
- 43. Exemplos de Relacionamento N:N (ou N:M) AUTOR MUSICA N N AUTOR_MUSICA 11 ALUNO DISCIPLINA N NALUNO_DISCIPLINA 11
- 44. Exemplos de Relacionamento N:N (ou N:M) PRODUTO PEDIDO N NPRODUTO_PEDIDO 11
- 45. Relacionamento N:N (ou N:M) • Relacionamentos podem ter atributos. Por exemplo, o relacionamento N:N para indicar a associação de Materiais com seus Fornecedores pode indicar para cada par do relacionamento, o preço, o prazo e lote (quantidade) que o fornecedor estabelece para fornecer o material.
- 46. Relacionamento N:N (ou N:M) • A Figura abaixo mostra a representação gráfica desse relacionamento. Materiais FornecedoresFornecer N N prazo preço quantidade
- 47. Conjunto de entidades fracos • Há casos em que a existência de um CE está vinculada à existência de outro CE. • Um exemplo típico é o registro, para fins de seguro-saúde ou imposto de renda, dos dependentes de um funcionário. • Nesse caso o registro só faz sentido para a empresa porque o dependente está ligado ao funcionário.
- 48. Conjunto de entidades fracos • Diz-se, então, que o CE “Dependentes” é um conjunto de entidades fraco. • O CE funcionários é as vezes chamado conjunto pai conjunto mestre e dependentes é as vezes chamado de conjunto detalhe.
- 49. Conjunto de entidades fracos FUNCIONARIO DEPENDENTE 1 N
- 50. Auto-relacionamentos • Muitas vezes queremos fazer o relacionamento de um CE consigo mesmo. Por exemplo, dado o CE “Peças” queremos saber quais peças são componentes de uma dada peça ou, dada peça quais peças tem a têm como componente. • Esses dois relacionamentos podem ser representados pelo diagrama da figura abaixo.
- 51. Auto-relacionamentos • Observe que cada uma das ligações do losango com o CE Peças recebeu um rótulo. • O primeiro rótulo significa: “uma peça é um componente” de outra peça, e o segundo rótulo significa “uma peça tem como componente” outra peça.
- 52. Auto-relacionamentos • Os rótulos de ligações explicitam o papel que a peça desempenha no relacionamento, Este papel é normalmente evidente nos relacionamentos. • Observe também que o relacionamento é de cardinalidade N;N, isto é, uma peça pode ter vários componentes e uma dada peça pode ser componente de várias peças.
- 53. Auto-relacionamentos Peças Composições N Tem como componente N É componente Quantidade
- 54. Grau de relacionamento • Os exemplos vistos até agora são de relacionamento envolvendo dois CE´s. Eles são ditos binários ou de grau 2 e são os mais comuns na prática. O grau de um relacionamento é um número de CE´s envolvidos no relacionamento. A figura abaixo mostra um relacionamento de grau 3, ou triplo, entre professores, alunos e disciplinas.
- 55. Grau de relacionamento • A cardinalidade desse relacionamento, 1 : N : N, pode ser interpretada da seguinte forma: - dado um professor e uma determinada disciplina temos diversos alunos; - dado um professor e um determinado aluno, temos diversas disciplinas; - dado um aluno e uma certa disciplina, temos um único professor;
- 56. Grau de relacionamento Professor Alunos Disciplinas PAD 1 N N
- 57. Grau de relacionamento • A figura mostra um relacionamento triplo chamado MRP entre Materiais, Pedidos e Requisições Materiais Requisições Pedidos N N N quantidade requisitada quantidade pedida MRP
- 58. Agregações • Há casos em que relacionamentos de grau superior a 2 não capturam as regras de negócio desejadas. • Por exemplo, no relacionamento triplo MRP visto anteriormente em materiais, requisições e pedidos (ordens de compra), uma requisição está relacionada com um ou mais materiais e com um ou mais pedidos (ou com nenhum deles), o que é artificial
- 59. Agregações • Esta separação de funções implica na existência de dois relacionamentos distintos; o segundo é chamado de agregação porque o relacionamento de Materiais com Requisição é agregado em um pseudo CE, que por sua vez se relaciona com Pedidos através do relacionamento “Itens de pedidos”
- 60. Agregações Materiais RequisiçõesItens de requisiçõ es Quant. requisitada N Pedidos N Itens de pedidos Quant. pedida
- 61. Especificação • As técnicas de orientação a objetos tiveram várias influencias sobre o projeto de bases de dados. • Uma delas é o conceito de subclasse e herança. • Muitas vezes queremos registrar características especiais de certos subconjuntos de um CE.
- 62. Especificação Funcionario Secretária Tecnico Engenheiro Nome NumF Gerente Línguas Grau Especializ. Engenheiros-GerenteAnos- exper
- 63. Especificação • Esses novos CE´s são também chamados de especializações do CE Funcionários. Como o nome “é-um” indica, o relacionamento significa que uma secretária “é uma” funcionária, isto é, possui todos os atributos do CE funcionário. • O símbolo “+” indica que a especialização é do tipo “ou exclusivo”, ou seja, um funcionário pode ser especializado em apenas um dentre “Secretárias”, “Técnicos” e “Gerentes”.
- 64. Integridade referencial • É um mecanismo utilizado para manter a consistência das informações gravadas. • Dessa forma, não são permitidas a entrada de valores duplicados nem a existência de uma referência a uma chave inválida em uma entidade.
- 65. Integridade referencial • É também necessário que cada valor de chave estrangeira possua uma ocorrência na outra entidade à qual faz referência. • Se isso não ocorrer, fica claro que estaremos perdendo uma informação importante para o sistema.
- 66. Integridade referencial • A maior parte dos bancos de dados relacionais estabelece esse tipo de relacionamento e impede que durante uma inclusão, exclusão ou alteração uma chave estrangeira de uma entidade não tenha correspondente na chave primária da outra entidade.
- 67. Integridade referencial • No caso de uma alteração ou exclusão na chave primária da entidade, deve-se verificar se há registros dependentes (chave estrangeira) nas demais tabelas. • Se houver, deve-se excluir todos os registros dependentes ou altera-los, dependendo do caso
Notas do Editor
- Nota-se, portanto, que ao utilizarmos o conceito de atributos em entidades estamos querendo qualificar ao máximo aquele objeto do mundo real. Essas informações muitas vezes não correspondem a todas as informações possíveis daquele objeto, mas sim às informações relevantes para o funcionamento do sistema.
- No exemplo do catálogo de CDs, não teremos cada um dos CDs armazenados no banco de dados, mas sim as características que nos permitirão identificar qual CD o cliente quer comprar, quais músicas há naquele CD, autores, gravadoras etc. Não importa se há várias unidades do mesmo CD disponíveis para venda na loja (a menos que se esteja desenvolvendo um sistema que controle o estoque cd CDs). Esta deve ser uma preocupação quando estivermos desenvolvendo um novo sistema – até onde exatamente queremos chegar com o sistema
- Nota-se, portanto, que ao utilizarmos o conceito de atributos em entidades estamos querendo qualificar ao máximo aquele objeto do mundo real. Essas informações muitas vezes não correspondem a todas as informações possíveis daquele objeto, mas sim às informações relevantes para o funcionamento do sistema.
- Caso não exista um atributo que possa assumir a posição de chave primária, é preciso cria-lo. Veja que nem todos campos é uma boa chave. Normalmente utilizamos campos numéricos por serem localizados mais rapidamente pelos bancos de dados. Valores alfanuméricos grandes têm acesso mais lento. Dessa forma, fica claro que toda tabela deve conter uma chave primária. Muitas vezes encontramos o termo superchave para identificar a chave primária. Trata-se apenas de um nome diferente para designar a mesma coisa, e, portanto não é preciso se preocupar com isso.
- Convenção para utilização em Diagramas Deve-se utilizar uma caixa de qualquer dimensão com um nome único (exclusivo) em cada uma das caixas. Esses nomes devem representar as Entidades do sistema. Alguns autores preferem utilizar a caixa com bordas arredondadas. Isso é apenas uma convenção diferente, que em nada modificará o objetivo e a compreensão da Entidade. A seguir será utilizado o nome da Entidade de fora da caixa e separada a Chave primária dos demais atributos com uma linha horizontal: |----------------| |CD | |----------------| |Código CD | |Nome CD | |Preço | |----------------|
- Note que esse relacionamento é efetivamente raro. Relacionamentos em que seja obrigatória em ambas as entidades são mais raros ainda. No exemplo a seguir, cada departamento é gerenciado por um gerente, e cada gerente gerencia um departamento. As chaves são distintas (são objetos absolutamente diferentes), mas é interessante nos questionarmos, mesmo que eventualmente, se um gerente não pode gerenciar mais de um departamento. Isso pode ou não ocorrer, dependendo da empresa, mesmo que seja por um curto período de tempo. Nesse caso, o relacionamento deveria ser trocado para um para muitos (1:n); Isso também ocorre com o relacionamento entre Computador e Para Mãe. Essa pergunta deve ser feita à possibilidade de um computador possuir mais de uma Placa Mãe no futuro.
- Note que esse relacionamento é efetivamente raro. Relacionamentos em que seja obrigatória em ambas as entidades são mais raros ainda. No exemplo a seguir, cada departamento é gerenciado por um gerente, e cada gerente gerencia um departamento. As chaves são distintas (são objetos absolutamente diferentes), mas é interessante nos questionarmos, mesmo que eventualmente, se um gerente não pode gerenciar mais de um departamento. Isso pode ou não ocorrer, dependendo da empresa, mesmo que seja por um curto período de tempo. Nesse caso, o relacionamento deveria ser trocado para um para muitos (1:n); Isso também ocorre com o relacionamento entre Computador e Para Mãe. Essa pergunta deve ser feita à possibilidade de um computador possuir mais de uma Placa Mãe no futuro.
- Relacionamentos desse tipo raramente são obrigatórios em ambas as entidades. A exceção é quando se trata de itens de uma entidade, como itens de nota fiscal ou pedidos. Mas esse parece ser um caso especial de muitos para muitos. A seguir, exemplos em que isso ocorre: Cada Gravadora grava vários CDs e cada CD é gravado apenas por uma Gravadora. Cada Cliente possui vários Pedidos e cada Pedido é de um único Cliente.
- Neste exemplo, vários funcionários podem estar lotados num único departamento. Dizemos então que o relacionamento Lotações de Funcionários com Departamento é de cardinalidade N para 1 ou N : 1. A cardinalidade do relacionamento está indicada pelos símbolos N e 1. Para determinar sua posição correta pode-se usar o seguinte argumento: “um funcionário existe em um único departamento e em um único departamento podem existir vários funcionários”.
- Esse relacionamento somente é possível na modelagem lógica de dados, uma vez que não se consegue implanta-lo em banco de dados relacionais. Ele será transformado em dois relacionamentos: um para muitos (1:n) e uma Entidade Associativa Atributiva será identificada, caso haja outras informações que devam ser agregadas a esta nova entidade – por exemplo de item de pedido em que se identificam quantidade e preço, ou criada, caso seja a simples união das chaves primárias de ambas as entidades – caso de vários produtos serem fornecidos por vários fornecedores e vice-versa.Esses relacionamentos são facilmente encontrados e normalmente são opcionais em ambas entidades. Existem casos em que há opcionalidade de apenas em uma das duas direções. Nos exemplos a seguir, cada Música é composta por um ou vários Autores, e cada Autor pode compor uma ou várias Músicas. Cada Produto é fornecido por vários Fornecedores e cada Fornecedor pode fornecer vários Produtos. E, finalmente, cada Aluno é inscrito em uma ou várias Matérias e cada Matéria possui vários Alunos.
- Neste exemplo, se uma entidade de um CE está associada a várias outras entidades de outro CE e vice-versa. só pode estar associada a uma única entidade de outro CE e vice-versa, dizemos então que o relacionamento é de cardinalidade N para N ou N:N.
- Note que os relacionamentos das Entidades Associativas recebem de ambas as entidades fundamentais o lado “muitos” do relacionamento. Por sua vez, do lado das entidades fundamentais, fica o lado “um” do relacionamento
- Poderíamos questionar nesse exemplo se um dado atributo, digamos, preço, pertence de fato ao relacionamento em vez de a um dos conjuntos de entidades envolvidos. Um teste simples é capaz de esclarecer a dúvida. Fixe o material e varie o fornecedor: se o preço varia, então o atributo não é do material; em seguida, fixe o fornecedor e varie o material: se o preço varia, então o atributo não é do fornecedor. Fica claro, nesse caso, que o atributo preço é do relacionamento, isto é, cada par (material, fornecedor) possui um preço. Idem aos atributos prazo e lote.
- A figura mostra um relacionamento triplo chamado MRP entre Materiais, Pedidos e Requisições, típico de um sistema de compras de materiais, onde requisições vindas de diversos setores são agrupadas em pedidos ou ordens de compra e se deseja relacionar cada pedido com as requisições originais. O relacionamento possui dois atributos: quantidade requisitada e quantidade pedida. O relacionamento tem cardinalidade N : N : N e é total do lado de Pedidos e de Requisições (toda requisição está associada a um ou mais pedidos e pode conter vários materiais, idem para pedidos), mas é parcial do lado de Materiais (um dado material pode não estar sendo comprado no momento).
- Há casos em que relacionamentos de grau superior a 2 não capturam as regras de negócio desejadas. Por exemplo, no relacionamento triplo MRP visto anteriormente em materiais, requisições e pedidos (ordens de compra), uma requisição está relacionada com um ou mais materiais e com um ou mais pedidos (ou com nenhum deles), o que é artificial. Requisições precedem a pedidos no tempo e originalmente estão relacionadas apenas com Materiais, já que toda requisição é criada para comprar um ou mais materiais. Elas se originam em diversos setores da empresa e são encaminhadas ao setor de compras. O setor de compras associa um pedido de compra ao par (requisição, material), portanto, ao relacionamento, especificando a quantidade a ser comprada ( que pode ser diferente da requisitada, por exemplo, para obter um desconto maior ou devido a alguma restrição de tamanho de lote de venda). Esta separação de funções implica na existência de dois relacionamentos distintos; o segundo é chamado de agregação porque o relacionamento de Materiais com Requisição é agregado em um pseudo CE, que por sua vez se relaciona com Pedidos através do relacionamento “Itens de pedidos”
- Posteriormente, no mapeamento do modelo conceitual para o modelo relacional, os relacionamentos N : N serão representados por tabelas auxiliares e, portanto, se comportam como CE´s, o que torna muito simples representar esse relacionamento especial no modelo relacional.
- As técnicas de orientação a objetos tiveram várias influencias sobre o projeto de bases de dados. Uma delas é o conceito de subclasse e herança. Muitas vezes queremos registrar características especiais de certos subconjuntos de um CE. Por exemplo, no CE Funcionários temos secretária, técnicos, engenheiros, gerentes etc, e para cada uma dessas categorias queremos guardar alguns atributos específicos, como habilidades das secretárias em digitação, informática, línguas etc. Outros atributos seriam requeridos para engenheiros e assim por diante. Seria ineficiente estender o CE Funcionários com todos esses atributos que só teriam valores para cada grupo específico de funcionários ficando vazios os não correspondentes ao grupo. Para este fin criamos os CE´s denominados Secretárias, Técnicos, Engenheiros etc, e um tipo especial de relacionamentos desses CE´s chamado “é um” e representado por um triangulo.
- É um mecanismo utilizado para manter a consistência das informações gravadas. Dessa forma, não são permitidas a entrada de valores duplicados nem a existência de uma referência a uma chave inválida em uma entidade. É importante enfatizar o conceito de integridade referencial. É também necessário que cada valor de chave estrangeira possua uma ocorrência na outra entidade à qual faz referência. Se isso não ocorrer, fica claro que estaremos perdendo uma informação importante para o sistema. Exemplo: se tivermos um valor na entidade CD correspondente à gravadora (chave estrangeira) e não tivermos o mesmo valor (chave primária) na entidade Gravadora, estaremos diante de um problema, pois teríamos um CD sem uma Gravadora válida.
- A maior parte dos bancos de dados relacionais estabelece esse tipo de relacionamento e impede que durante uma inclusão, exclusão ou alteração uma chave estrangeira de uma entidade não tenha correspondente na chave primária da outra entidade. Assim, em uma inclusão na entidade com a chave estrangeira, caso seja informado um código que não exista, correspondente na outra entidade, deve ser gerada uma mensagem de erro. Assim, caso queiramos incluir um CD com um código de Gravadora que não exista, correspondente na tabela Gravadora, deve ser enviada uma mensagem de erro e impedida a gravação da informação.
- No caso de uma alteração ou exclusão na chave primária da entidade, deve-se verificar se há registros dependentes (chave estrangeira) nas demais tabelas. Se houver, deve-se excluir todos os registros dependentes ou altera-los, dependendo do caso. Isso poderia ocorrer caso quiséssemos excluir ou alterar uma Gravadora e tivéssemos CDs armazenados com o código da Gravadora. Se fosse permitido, teríamos uma informação inválida, pois ao tentarmos localizar a Gravadora deste CD, isso não seria possível. Caso o seu banco de dados não disponha desse recurso, você deverá levar isso em consideração e criar mecanismos que evitem o problema. Quanto o banco de dados dispuser desse recurso, este adotará o nome CONSTRAINT. Em alguns bancos de dados é possível controlar até a propagação de exclusões ou alterações na chave primária: ou se apagam todos os registros dependentes ou se altera o seu código. Assim, caso excluíssemos ou alterássemos uma determinada Gravadora, todos os CDs dessa gravadora seriam automaticamente excluídos ou alterados. Note que isso é bastante perigoso, pois normalmente nenhuma mensagem será dada ao usuário. A regra será a automática modificação das informações no banco de dados.