Introdução a banco de dados à Modelagem e Projeto de Banco de Dados

1. Introdução a banco de dados à Modelagem e Projeto de Banco de Dados Marcelo Mendes BANCO DE DADOS Março 2013 - FUCAPI

2. OBJETIVOS: • Modelagem de dados de sistemas típicos através do Modelo Entidade Relacionamento. • Conceitos e projeto lógico do Modelo Relacional • Práticas de Modelagem e Projeto Fucapi

3. BIBLIOGRAFIA • Fundamentals of Database Systems Elmasri, R; Navathe, S Benjamin Cummings, 1994 • Sistemas de banco de Dados Korth, H. F.; Silberschatz, A; Sudarshan, S Makkron Books, 1999 • Introdução a Sistemas de Bancos de Dados Date, C. J. , Editora Campus, 2000 Fucapi

4. BANCO DE DADOS • “É uma coleção de dados inter-relacionados, representando informações sobre um domínio específico (conceito geral) • Representa aspectos do mundo real. Mudanças no mundo real são refletidas no BD • É uma coleção lógica e coerente de dados com relacionamentos intrínsecos; • É projetado, construído, e mantido para uma proposta específica. É direcionado a um grupo de usuários/aplicação • Pode ter qualquer tamanho/complexidade Fucapi

5. Processo de Solução Mundo Real Solução MODELOS DE DADOS Modelo Modelo é a representação abstrata e simplificada de uma determinada realidade. É um conjunto de conceitos para descrever os dados, de restrições e relacionamento entre esses dados. Fucapi

6. BANCO DE DADOS • Éum conjunto de registros dispostos em estrutura regular que possibilita a reorganização dos mesmos e produção de informação. • Um banco de dados normalmente agrupa registros utilizáveis para um mesmo fim. • Um banco de dados é usualmente mantido e acessado por meio de um software conhecido como Sistema Gerenciador de Banco de Dados (SGBD). • Normalmente um SGBD adota um modelo de dados, de forma pura, reduzida ou estendida. Muitas vezes o termo banco de dados é usado, de forma errônea, como sinônimo de SGDB. Fucapi

7. BANCO DE DADOS • Os sistemas de gestão de banco de dados possuem características especiais para o armazenamento, classificação, gestão da integridade e recuperação dos dados. • Com a evolução de padrões de conectividade entre as tabelas de um banco de dados e programas desenvolvidos em linguagens como Java, Delphi, Visual Basic, C++ etc. • Como hoje em dia a maioria das linguagens de programação fazem ligações a bancos de dados, a apresentação destes tem ficado cada vez mais a critério dos meios de programação, fazendo com que os bancos de dados deixem de restringir-se às pesquisas básicas, dando lugar ao compartilhamento, em tempo real, de informações, mecanismos de busca inteligentes e permissividade de acesso hierarquizada. Fucapi

8. SGBD • Sistema Gerenciador de Bancos de Dados (SGBD): • Software construıdopara facilitar as atividades de definição, • construção e manipulação de bancos de dados; • Consistem em uma coleção de dados inter-relacionados • e de um conjunto de programas • para acessá-los • Sistema de Bancos de Dados: Banco de Dados + Software • que o manipula Fucapi

9. Objetivos do SGBD • Prover um ambiente que seja conveniente e eficiente para recuperar e armazenar informações de Bancos de Dados. • Eliminar ou Reduzir • Redundância e inconsistência de dados • Dificuldade no acesso aos dados • Isolamento dos dados • Anomalias de acesso concorrente • Problemas de segurança • Abstração de dados • Simplifica a interação do usuário com o Sistema Fucapi

10. SGBD Fucapi

11. Funções do SGBD 1.Controle de Redundância; 2. Compartilhamento de Dados; 3. Controle de Acesso aos Dados; 4. Múltiplas Interfaces; 5. Representação de associações complexas; 6. Garantia de restrições de Integridade; 7. Recuperação de falhas Fucapi

12. Modelo de Entidade do Modelo do cliente Modelo dosistema na mente do cliente Representação Tabular do modelode entidade Server Tabelas no disco MODELOS DE DADOS Fucapi a1

13. Mundo Real Nível Conceitual nível lógico nível físico Níveis de Abstração de BD Modelo Entidade Relacionamento Modelo Relacional-Objeto Relacional Fucapi

14. Níveis de Abstração de BD Modelo conceitual É a descrição do BD de maneira independente ao SGBD, ou seja, define quais os dados que aparecerão no BD, mas sem se importar com a implementação que se dará ao BD. Desta forma, há uma abstração em nível de SGBD. Uma das técnicas mais utilizadas dentre os profissionais da área é a abordagem entidade-relacionamento (ER), onde o modelo é representado graficamente através do diagrama entidade-relacionamento (DER) . Fucapi

15. Níveis de Abstração de BD Modelo Lógico Descreve o BD no nível do SGBD, ou seja, depende do tipo particular de SGBD que será usado. Não podemos confundir com o Software que será usado. O tipo de SGBD que o modelo lógico trata é se o mesmo é relacional, orientado a objetos, hierárquico, etc. Abordaremos o SGBD relacional, por serem os mais difundidos. Nele, os dados são organizados em tabelas. Fucapi

16. Níveis de Abstração de BD Fucapi

17. Níveis de Abstração de BD O modelo lógico do BD relacional deve definir quais as tabelas e o nome das colunas que compõem estas tabelas. Para o nosso exemplo, poderíamos definir nosso modelo lógico conforme o seguinte: Aluno(mat_aluno, nome, endereco)Turma (cod_turma, sala, periodo) É importante salientar que os detalhes internos de armazenamento, por exemplo, não são descritos no modelo lógico, pois estas informações fazem parte do modelo físico, que nada mais é que a tradução do modelo lógico para a linguagem do software escolhido para implementar o sistema. Fucapi

18. Níveis de Abstração de BD Nível físico: o nível mais baixo de abstração descreve como os dados estão realmente armazenados. No nível físico, complexas estruturas de dados de baixo nível são descritas em detalhes; É importante salientar que os detalhes internos de armazenamento, por exemplo, não são descritos no modelo lógico, pois estas informações fazem parte do modelo físico, que nada mais é que a tradução do modelo lógico para a linguagem do software escolhido para implementar o sistema. Fucapi

19. Níveis de Abstração de BD Projeto de Banco de Dados NOME: Funcionários OBJETIVO: Armazena informações referentes aos funcionários. Fucapi

20. AlgebraRealcional Conceito A Álgebra Relacional é uma linguagem de consulta formal, porém procedimental, ou seja, o usuário dá as instruções ao sistema para que o mesmo realize uma seqüência de operações na base de dados para calcular o resultado desejado. Fucapi

21. AlgebraRealcional A discussão sobre algumas operações básicas de álgebra relacional realizada a seguir considera um banco de dados composto pelas seguintes relações: funcionário (NrMatric, NmFunc, DtAdm, Sexo, CdCargo, CdDepto) cargo (CdCargo, NmCargo, VrSalario) depto (CdDepto, NmDepto, Ramal) Os atributos sublinhados com linha contínua indicam a chave primária de cada relação enquanto que aqueles sublinhados com linha pontilhada constituem chaves estrangeiras. Fucapi

22. AlgebraRealcional Fucapi

23. AlgebraRealcional Estamos interessados em obter informações armazenadas nesse banco de dados, e para isso deveremos formular expressões em álgebra relacional combinando apenas algumas operações primitivas clássicas, que serão apresentadas uma a uma de forma implificada em termos de seu significado prático e notação. Toda operação relacional opera (age) sobre um ou mais conjuntos de dados e fornece como resultado um novo conjunto. Devido a essa característica, podemos combinar mais de uma operação relacional em uma única expressão algébrica, fazendo com que o resultado de uma operação seja utilizado como entrada para outra operação, aumentando com isso grandemente o poder dessa linguagem de consulta. Suponha que, inicialmente, precisamos obter o nome completo de todos os funcionários de nosso banco de dados. Para isso será necessário executar uma operação chamada Projeção. Fucapi

24. AlgebraRealcional-Projeção Geralmente indicada na literatura por (a letra grega pi) produz um conjunto onde há um elemento para cada elemento do conjunto de entrada, sendo que a estrutura dos membros do conjunto resultante é definida nos argumentos da operação. Pode ser entendida como uma operação que filtra as colunas de uma tabela. Por operar sobre apenas um conjunto de entrada, a projeção é classificada como uma operação unária. Ex.: NmFunc (funcionário) essa expressão produz um conjunto contendo um elemento para cada funcionário, e cada elemento contém apenas a informação referente a NmFunc da relação funcionário original. Fucapi

25. AlgebraRealcional-Projeção Fucapi

26. AlgebraRealcional-Projeção Agora estamos interessados em identificar todos os funcionários de sexo masculino existentes no banco de dados. É uma situação que não podemos resolver com projeções apenas, uma vez que deveremos descartar elementos do conjunto inicial. Para casos desse tipo existe uma operação relacional chamada Seleção. Seleção (ou Restrição) Indicada por s (a letra grega sigma), é uma operação que para um conjunto inicial fornecido como argumento, produz um subconjunto estruturalmente idêntico, mas apenas com os elementos do conjunto original que atendem a uma determinada condição (também chamada de predicado). A seleção pode ser entendida como uma operação que filtra as linhas de uma tabela, e é também uma operação unária, já que opera sobre um único conjunto de dados. Ex.: Sexo = ‘M’ (funcionário) produz o conjunto dos elementos de funcionário que atendem ao predicado [Sexo = ‘M’], ou seja, representa um subconjunto dos funcionários para o qual essa condição é avaliada como verdadeira. Fucapi

27. AlgebraRealcional-Projeção Fucapi

28. AlgebraRealcional-Projeção No caso de querermos descobrir o nome completo e a data de admissão de todos os funcionários do sexo feminino existentes na empresa, será necessário combinar uma projeção com uma seleção. Isso porque se decidirmos projetar as colunas desejadas diretamente a partir da relação funcionário, estaremos considerando também os elementos do sexo masculino, o que não queremos. Como a projeção não permite descartar linhas, apenas colunas, deveremos fornecer a essa operação o subconjunto resultante de uma filtragem (seleção) da relação de funcionários original, como mostram as duas figuras a seguir, que representam as relações e as operações de duas maneiras diferentes. Fucapi

29. AlgebraRealcional-Projeção Fucapi

30. AlgebraRealcional-Projeção Assim, a expressão que atende nossos objetivos nesse caso é cabendo observar que devido ao alinhamento das operações está implícito que primeiro será executada a seleção e depois a projeção, sendo que nesse exemplo não poderíamos inverter essa ordem (você poderia explicar porquê?). Por esse motivo, dizemos que a álgebra relacional é uma linguagem procedural, já que requer alguma definição quanto à ordem em que as operações serão realizadas. Linguagens em que apenas mencionamos o resultado desejado, sem fazer menção alguma à forma como isso deve ser feito são chamadas de linguagens não-procedurais. Fucapi

31. Algebra Realcional- Produto cartesiano Suponha agora que precisamos obter o nome completo, a data de admissão e o salário de cada funcionário cadastrado. Para essa consulta temos um fato novo, que é a referência a colunas de mais de uma tabela, uma vez que o nome e a data de admissão fazem parte da relação funcionário, enquanto que o salário existe apenas em cargos. Isso é problemático, pois as duas operações que conhecemos até o momento são unárias, e temos necessidade de combinar os dados de mais de uma relação. Para situações como essa existe uma operação chamada Produto Cartesiano. Fucapi

32. Algebra Realcional- Produto cartesiano A notação geralmente adotada (na forma ‘conjunto1 x conjunto2’) para representar essa operação binária indica bem a sua natureza: o resultado do produto cartesiano de duas tabelas é uma terceira tabela contendo todas as combinações possíveis entre os elementos das tabelas originais. Essa tabela resultante possuirá um número de colunas que é igual à soma das quantidades de colunas das duas tabelas iniciais, e um número de linhas igual ao produto do número de suas linhas. Portanto, se fizermos o produto cartesiano de uma tabela A que possua 4 colunas e 10 linhas com uma tabela B onde existem 3 colunas e 7 linhas, a tabela resultante terá 4+3= 7 colunas e 10*7= 70 linhas. Assim, cada linha dessa tabela corresponderá à concatenação de uma linha da primeira tabela com uma linha da segunda. O produto cartesiano não é muito usado como um fim em si mesmo, ou seja, dificilmente estaremos interessados em saber quais são todas as combinações possíveis entre as linhas de duas tabelas, pois a utilidade prática desse tipo de conhecimento é muito discutível. Entretanto, é a única forma primitiva de que dispomos para fundir informações de duas tabelas heterogêneas para posterior processamento. Nesse caso, tipicamente será necessário executar uma Seleção sobre o resultado do Produto Cartesiano, de maneira a descartar as combinações inválidas entre as linhas das tabelas originais. Fucapi

33. Algebra Realcional- Produto cartesiano observe que primeiro é produzido o produto cartesiano correspondente a todas as combinações possíveis entre funcionários e cargos. Essa relação vai conter linhas onde um funcionário estará associado a cargos que não são o seu, e devemos então aplicar um filtro (uma seleção) para gerar um subconjunto apenas com as combinações logicamente válidas (aquelas em que a chave estrangeira CdCargo de funcionário tem valor igual á chave primária CdCargo de cargo). Como temos nesse subconjunto duas colunas com o mesmo nome (CdCargo que veio de funcionário e CdCargo proveniente de cargo), sempre que precisarmos mencionar uma delas será necessário especificar exatamente a qual das duas colunas estamos nos referindo, senão teremos uma situação ambígua, formalmente inaceitável. Dizemos, nesse caso, que é necessário qualificar a coluna, e isso é feito escrevendo o nome da relação original antes do nome da coluna, separando-os por um ponto, ou seja, <nome-da-relação>.<nome-da-coluna>. É por esse motivo que escrevemos o predicado da seleção como sendo funcionário.CdCargo = cargo.CdCargo. Finalmente, a projeção é realizada a partir desse subconjunto, fornecendo os dados inicialmente desejados. Fucapi

34. Algebra Realcional- Produto cartesiano Fucapi

35. Algebra Realcional- Produto cartesiano Fucapi

36. Algebra Realcional- Produto cartesiano Fucapi

37. Algebra Realcional- Produto cartesiano Fucapi

38. Algebra Realcional- Produto cartesiano Caso desejemos obter uma variação ligeiramente diferente dessa consulta, acrescentando a restrição de que precisamos dos dados apenas dos funcionários do sexo masculino, teríamos a seguinte expressão algébrica: onde o símbolo Ù presente no predicado representa o conectivo lógico “E”. Portanto, com apenas 3 operações relacionais básicas foi possível extrair do banco de dados de exemplo várias informações importantes, representativas de uma grande parcela das consultas que um sistema gerenciador de bancos de dados deve processar. Fucapi

39. Algebra Realcional- Produto cartesiano As consultas realizadas foram: 1. obter o nome completo de todos os funcionários; 2. identificar todos os funcionários do sexo masculino; 3. obter o nome completo e a data de admissão de todos os funcionários do sexo feminino; 4. obter o nome completo, a data de admissão e o salário de todos os funcionários; 5. descobrir o nome completo, a data de admissão e o salário de todos os funcionários do sexo masculino. Fucapi

40. Modelo Entidade Relacionamento - MER • Proporciona uma visão lógica de alto nível dos dados • É uma descrição abstrata de uma porção do mundo real • Todos os dados são visualizados como fatos específicos sobre entidades, relacionamentos e atributos • Através do MER, podemos ter uma fotografia do sistema • As entidades, relacionamentos e atributos descrevem as regras de negócio da empresa Fucapi

41. Modelo Entidade Relacionamento - MER Modelo Entidade-Relacionamento (MER) Original: • – Fases do Projeto de Bases de Dados • – Definição e Objetivo do Modelo ER • – Entidades e Conjuntos-Entidade • – Atributos e Domínio de um Atributo • – Relacionamentos e Conjuntos-Relacionamento • – Projeto de Chaves • – Grau de um Relacionamento • – Restrições de Cardinalidade e Integridade Referencial Fucapi

42. Modelo Entidade Relacionamento - MER • Extensões e Variações do MER : • – Agregação • – Generalização/Especialização • – Notação, Variações e Exemplos • – Dicas para Elaboração de Modelos E-R Fucapi

43. Modelo Entidade Relacionamento - MER • Definição: modelo baseado na percepção do mundo real que consiste em um conjunto de objetos básicos, chamados entidades, e nos relacionamentos entre esses objetos. • Objetivo: facilitar o projeto de banco de dados, possibilitando especificar a estrutura lógica geral. Fucapi

44. Modelo Entidade Relacionamento - MER Atributo Relacionamento Entidade Fucapi

45. z Modelo Entidade Relacionamento - Convenções Entidade Entidade Fraca Relacionamento Relacionamento Identificador Atributo Atributo Identificador Atributo Multivalorado Fucapi

46. ... Atributo Composto Atributo Derivado Participação total de E2 em R Ex: Agência e Conta Corrente R E2 E1 Cardinalidade 1:N para E1:E2 em R 1 R N E1 E2 Constraint (min,max) de E em R R (min,max) E2 E1 Modelo Entidade Relacionamento - Convenções Fucapi

47. Fucapi

48. COMPONENTES DO MER • ENTIDADE • Qualquer coisa para a qual desejamos guardar informação • Conjunto de objetos individuais chamados instâncias • Uma instância deve ter uma identidade distinta de todas as outras Fucapi

49. TIPOS DE ENTIDADES • INDEPENDENTES (FORTES) • entidade que existe por si só • NOTAÇÃO : retângulo • RESTRIÇÕES • Não pode existir duas entidades com mesmo nome no modelo • DICA: • Geralmente tem mais de um atributo • O nome = substantivo • Substantivo é tudo o que nomeia as "coisas" em geral. • Substantivo é tudo o que pode ser visto, pego ou sentido. • Substantivo é tudo o que pode ser precedido de artigo. Fucapi

50. TIPOS DE ENTIDADES DEPENDENTES(FRACAS) • Entidades que dependem de outras para sua existência (dependência por existência) • Entidades que dependem de outras para sua identificação (dependência por identificação) • NOTAÇÃO: Retângulo duplo • RESTRIÇÕES • Só existe enquanto a entidade forte existir Fucapi