Curso Profissional de Técnico de Multimédia 11ºAno. Disciplina: Sistemas de Informação

Transcrição

1 Curso Profissional de Técnico de Multimédia 11ºAno Disciplina: Sistemas de Informação Módulo 5: Desenvolvimento de Bases de Dados 5.1. Modelo Relacional de Bases de Dados Bases de dados e tabelas Tabelas em bases de dados relacionais Relacionamentos entre tabelas Integridade da informação numa base de dados relacional Prof. Micael Alves

2 Bases de Dados e Tabelas N_aluno Modelo Relacional de Bases de Dados Nome Aluno (Entidade) N_aluno Linguagem comum nas bases de dados Colunas ou campos Linhas ou registos Aluno N_Aluno Nome Morada (Classe) Tabela N_Aluno Nome Localidade 1 Abel Lisboa 2 Ana Porto 3 Carla Coimbra 4 Daniel Funchal Linguagem formal do modelo relacional Atributos Tuplos Fig 1 As entidades dos diagramas ER ou as classes dos diagramas de classes vão corresponder a tabelas de bases de dados em que os atributos dão origem aos campos ou colunas dessas tabelas.

3 Bases de Dados e Tabelas Base de dados Uma base de dados pode ser definida como um conjunto estruturado de dados armazenado num suporte informático, de uma forma acessível à consulta e manipulação por parte dos utilizadores. O software que permite criar e/ou gerir uma base de dados costuma ser designado por SGBD Sistema de Gestão de Bases de Dados.

4 Bases de Dados e Tabelas Um SGBD é concebido para poder implementar bases de dados segundo um determinado modelo. Desde a década de 80 que o modelo de bases de dados mais difundido e utilizado nos sistemas de informação e em geral é o modelo relacional. O modelo relacional foi criado por um grupo de trabalho dirigido por Edgar Codd, cerca de Neste modelo, a estrutura básica é a tabela que é vista como uma relação de dados.

5 Bases de Dados e Tabelas Foi a palavra inglesa relation que deu origem ao nome do modelo relacional e não, ao contrário do que por vezes se pensa, as relações ou relacionamentos (relationship, em inglês) entre as tabelas que também são uma característica fundamental deste modelo.

6 Bases de Dados e Tabelas Tabelas Modelo Relacional de Bases de Dados Uma tabela é uma estrutura de dados formada por: 1 um conjunto de colunas, campos ou atributos (tudo sinónimos); 2 um conjunto de linhas, registos (ou ainda tuplos, na linguagem do modelo relacional). Como é fácil de constatar, uma tabela é uma estrutura de dados para armazenar informação sobre uma entidade ou classe.

7 Bases de Dados e Tabelas Na verdade, quando falámos de entidades (diagramas ER) e de classes (diagramas de classes), já tínhamos em vista que tanto urr como outras vão, em princípio, dar origem a tabelas de bases de dados (ver figura 1).

8 Bases de Dados e Tabelas Atributos ou campos N_Aluno Nome Localidade 1 Abel Lisboa 2 Ana Porto 3 Carla Coimbra 4 Daniel Funchal Linhas ou Registos Abel Carla Ana Daniel Lisboa Coimbra Porto Domínios Fig 2 Os domínios dos atributos (ou campos) correspondem aos tipos de dados que eles podem assumir.

9 Bases de Dados e Tabelas Atributos e campos Vimos que quer uma entidade quer uma classe são formadas por atributos. Vimos também que um atributo é uma propriedade ou característica de uma entidade que nos interessa registar num sistema ou base de dados. Nas bases de dados do modelo relacional, os atributos correspondem às colunas de uma tabela que também costumam ser designadas por campos. Por exemplo, na figura 1 ou 2, a tabela Alunos contém o seguinte conjunto de campos: N_Aluno; Nome; Localidade.

10 Bases de Dados e Tabelas Registos Modelo Relacional de Bases de Dados Por sua vez, as linhas de uma tabela correspondem a registos. Por conseguinte, um registo é constituído por um conjunto de dados (atributos ou campos) relativos a uma entidade singular ou um objeto. Por exemplo, na tabela Alunos da figura 1 ou 2, o conjunto dos dados (2, Ana, Porto) é um registo dessa tabela.

11 Bases de Dados e Tabelas Domínios dos atributos Um outro conceito muito importante que está relacionado com cada atributo (ou campo) de uma tabela é o de domínio. Como também já vimos (e se representa aqui de novo na figura 2), o domínio de um atributo (ou campo de uma tabela) corresponde aos valores ou tipos de dados que esse atributo (ou campo) pode assumir.

12 Bases de Dados e Tabelas Por exemplo, no campo N_Aluno, o domínio corresponde aos números inteiros que podem ser atribuídos aos alunos. Por sua vez, o campo Nome terá como domínio o conjunto dos nomes possíveis. O campo Localidade terá como domínio os nomes possíveis de localidades, etc. Como é fácil de ver, os domínios são importantes para a definição da estrutura de uma tabela, pois têm a ver com os tipos de dados com que um sistema informático e um SGBD pode trabalhar, tais como: inteiros, reais, datas, strings, etc.

13 Tabelas em bases de dados relacionais Tabela Alunos Chaves candidatas Tabela Chave candidata (?) Artigos N_Aluno Nome Localidade Designação Categoria Preço 1 Abel Silva Lisboa Portátil PP Computadores Ana Nunes Porto Impressora X Periféricos Carla Dias Porto Impressora Y Periféricos Eva Silva Lisboa Tinteiro Consumíveis 20 Chave primária Chave primária (?) Fig 3 Chaves candidatas e chave primária. Na tabela Alunos, temos duas chaves candidatas (N_Aluno e Nome). O campo N_Aluno foi selecionado para ser a chave primária. Na tabela Artigos, há apenas uma chave candidata: Designação (que não oferece garantias de não conter dados repetidos). Em situações como esta, o melhor é criar um campo de código para funcionar como chave primária.

14 Tabelas em bases de dados relacionais Chave primária e chaves candidatas No modelo relacional, para que uma tabela esteja bem definida deve, em princípio, ter uma chave primária. Uma chave primária é um atributo ou conjunto de atributos que permite identificar de forma unívoca cada registo numa tabela, sendo selecionado para esse efeito entre as possíveis chaves candidatas. Uma chave candidata é um atributo ou conjunto de atributos que permite identificar de forma unívoca cada registo numa tabela.

15 Tabelas em bases de dados relacionais Os dois conceitos são semelhantes; a única diferença é que a chave primária é selecionada entre as chaves candidatas para desempenhar essa função de identificar de forma unívoca cada registo numa tabela. Para compreendermos o significado deste conceito, vejamos as tabelas apresentadas na figura 3. Para que um atributo possa ser chave candidata não pode conter dados repetidos em diferentes registos (linhas da tabela) só assim pode identificar de forma única cada registo.

16 Tabelas em bases de dados relacionais Na tabela Alunos, os atributos que podem ser considerados chaves candidatas são: N_Aluno (número) e Nome. Localidade não pode, porque apresenta dados repetidos. Entre as duas chaves candidatas da tabela Alunos (N_Aluno e Nome), a melhor opção para a chave primária é N_Aluno, pois cada aluno terá um número único. O atributo Nome não é tão seguro quanto a esse aspeto, já que é possível surgirem nomes idênticos para alunos diferentes. Na tabela Artigos, tal como está apresentada, temos apenas uma chave candidata: Designação.

17 Tabelas em bases de dados relacionais Os outros campos apresentam dados que se repetem; logo, não podem ser chaves candidatas. Mas, mesmo o campo Designação não oferece garantia de não conter repetições para certos produtos. Em situações como esta, é prática usual criar um campo que ofereça essa garantia. Por exemplo, na tabela Artigos, podemos incluir um campo com um código para o produto (CodArtigo ou algo semelhante) e, então, passará esse campo a ser a chave primária da tabela.

18 Tabelas em bases de dados relacionais Fig 4 Uma tabela na vista de estrutura no MS Access

19 Tabelas em bases de dados relacionais Tabela Sócios Número: Integer <<PK>> Nome: String[50] {Obrigatório} Sexo: Char {Valores = [ M F ]} Data Nascimento: Date {Obrigatório} Morada: String Fig 5 Uma tabela na sua definição de estrutura

20 Tabelas em bases de dados relacionais Formas de representar uma tabela numa base de dados relacional As tabelas dos exemplos que vimos até aqui estão todas no seu formato mais habitual de um conjunto de colunas por um conjunto de linhas. Este formato de tabela também é, por vezes, designado por folha de dados ou vista de folha de dados. No entanto, também é prática habitual representar as tabelas de uma base de dados relacional através de outras formas convencionais.

21 Tabelas em bases de dados relacionais Na figura 4, temos uma tabela na vista de estrutura no SGBD MS Access. Na figura 5, temos uma tabela na vista de estrutura definida tecnicamente, antes de implementação num sistema de bases de dados. Neste caso, a tabela Sócios está representada vista de estrutura ou definição de estrutura porque temos apenas as definições técnicas dos campos dessa tabela (sem a folha de dados ).

22 Tabelas em bases de dados relacionais Essas definições técnicas dos campos da tabela assemelham-se a entradas de um dicionário de dados para uma tabela de uma base de dados. Cada campo da tabela inclui, após o respetivo nome, a indicação do seu tipo de dados, bem como outras indicações importantes, como se é chave primária, se é um campo de preenchimento obrigatório, valores default, valores opcionais, etc.

23 Tabelas em bases de dados relacionais Por exemplo, o campo Número está indicado como sendo do tipo Integer (inteiro) e <<PK>> - que quer dizer Primary Key, ou seja, chave primária. No campo Sexo, é indicado Char (carácter) e são explicitadas as únicas opções aceitáveis ["M" "F"] - caracteres M ou F. Há ainda uma outra forma de representar uma tabela, chamada representação analítica que é uma forma simplificada da vista de estrutura.

24 Tabelas em bases de dados relacionais Considerando o exemplo anterior da tabela Sócios, ela também pode ser representada assim: Sócio (Número, Nome, Sexo, DataNascimento, Morada) Neste caso, indica-se o nome da tabela, seguido da lista de atributos ou campos, dentro de parênteses curvos. O facto de o campo Número estar sublinhado indica que se trata da chave primária desta tabela.

25 Relacionamentos entre tabelas Artigo CodArtigo Designação CodForn. é fornecido Fornecedor CodForn Nome Morada Artigo CodArtigo Nome CodForn A1 Alicate F1 B2 Berbequim F1 C3 Serra F3 D4 Martelo F2 Fornecedor CodForn Nome Localidade F1 FerroXis Lisboa F2 Ferrantas Porto F3 Ambrósio Porto F4 Silva e Silva Lisboa Fig 6 Exemplo de um relacionamento entre duas tabelas. O campo CodForn, que é chave primária na tabela Fornecedor, aparece na tabela Artigo, onde toma o lugar de chave estrangeira.

26 Relacionamentos entre tabelas As bases de dados relacionais raramente consistem numa só tabela. O grande sucesso do modelo relacional deve-se ao facto de podermos combinar, numa mesma base de dados, uma multiplicidade de tabelas. Recordemos que os diagramas ER ou de classes se caracterizam por nos mostrarem como as entidades ou classes podem relacionar-se entre si. Consideremos, por exemplo (ver figura 6), a situação de uma empresa que comercializa um conjunto de artigos (tabela Artigo), que compra aos seus fornecedores (tabela Fornecedor).

27 Relacionamentos entre tabelas Num diagrama de classes, o relacionamento entre as duas entidades ou classes (tabelas) pode ser representado como é apresentado na parte superior da figura 6 e se reproduz aqui. Artigo CodArtigo Designação CodForn. é fornecido Fornecedor CodForn Nome Morada Fig 7 Relacionamento entre Artigo e Fornecedor. Na tabela Artigo, foi incluído o campo CodForn que é a chave primária da tabela Fornecedor.

28 Relacionamentos entre tabelas A questão que agora se coloca é: como é que esse relacionamento se traduz para uma base de dados relacional? Na versão apresentada na figura 6, esse relacionamento está traduzido da seguinte forma: - na tabela Artigo, foi incluído um campo CodForn que corresponde à chave primária da tabela Fornecedor; nesse campo são registados os códigos correspondentes aos fornecedores. Numa situação como esta, estamos perante o que se chama uma chave estrangeira (FK Foreign Key).

29 Relacionamentos entre tabelas Uma chave estrangeira é um campo importado para uma tabela, sendo chave primária na tabela de origem. Esta é a forma de estabelecer relacionamentos entre tabelas numa base de dados relacional. Consideremos como tabela principal aquela que contém a chave primária a ser importada (no nosso exemplo, é a tabela Fornecedor); e consideremos como tabela relacionada aquela que recebe a importação da chave primária que, nesta tabela que a recebe, passa a ser referida como chave estrangeira.

30 Relacionamentos entre tabelas Departamento 0..* 1..* Depart_Empreg Empregado Departamento Data_Empreg Empregado CodDep Nome CodDep CodEmp Data_Entrada CodEmp Nome D1 Produção D1 E1 E1 Aníbal D2 Marketing D2 E2 E2 Belmiro D3 Informática E3 Casimiro Fig 8 Exemplo de um relacionamento entre duas entidades ou tabelas que passa por uma entidade ou tabela de associação

31 Relacionamentos entre tabelas Às vezes, o relacionamento entre duas tabelas (entidades ou classes) passa por uma terceira tabela (entidade ou classe) de associação. Consideremos, por exemplo, a situação de uma empresa (ver figura 8), em que os empregados estão ligados aos vários departamentos da empresa na seguinte relação: - Cada empregado pode trabalhar em zero ou vários departamentos (0..*) e cada departamento pode ter um ou vários empregados (1..*); como os empregados podem passar de um departamento para outro, interessa registar a data de entrada em cada departamento e manter esses registos ao longo do tempo.

32 Relacionamentos entre tabelas Em situações como esta, não funciona importar a chave primária da tabela principal (neste caso, Departamento) para a outra tabela (neste caso, Empregado). Não podemos, simplesmente, colocar na tabela empregado o código do Departamento, pois pode haver empregados que não estão ligados a nenhum departamento e, além disso, interessa registar os vários departamentos por onde um empregado pode passar. Em situações como esta, a solução passa por criar uma tabela de relacionamento (entidade ou classe de associação).

33 Relacionamentos entre tabelas No nosso exemplo, criámos uma tabela com o nome Depart_Empreg para relacionar as duas tabelas originais (Departamento e Empregado). Na tabela Depart_Empreg, incluímos os seguintes campos: CodDep que é a chave primária da tabela Departamento e, portanto, funciona aqui como chave estrangeira; CodEmp que é a chave primária da tabela Empregado e funciona aqui também como outra chave estrangeira.

34 Relacionamentos entre tabelas Desta forma, cada registo que entrar na tabela Depart_Empreg terá de incluir um dado de CodDep da tabela Departamento e um dado de CodEmp da tabela Empregado. Repare-se que a chave primária desta tabela Depart_Empreg tem de ser composta por estes dois campos em simultâneo: CodDep e CodEmp. Só os dois em conjunto é que identificam de modo unívoco cada registo da tabela Depart_Empreg.

35 Integridade da informação numa base de dados relacional O modelo relacional obriga a que a realização das operações de atualização numa base de dados decorra de forma consistente. A manutenção da consistência ou integridade da informação numa base de dados deve ser assegurada pelo SGBD (ou pelas aplicações que forem criadas para aceder à base de dados).

36 Integridade da informação numa base de dados relacional Uma base de dados relacional deve assegurar dois tipos de integridade: 1 integridade de entidade; 2 integridade referencial. 1 A integridade de entidade impõe que os valores dos atributos que correspondem à chave primária de uma entidade não podem ser nulos nem iguais a outros já existentes na tabela.

37 Integridade da informação numa base de dados relacional A introdução de um valor nulo numa chave primária ou a inclusão nessa chave de um valor igual a outro já existente faria com que a chave deixasse de identificar de modo unívoco os registos da tabela; portanto, deixaria de poder funcionar como chave primária. 2 A integridade referencial impõe que um valor de uma chave externa exista obrigatoriamente como elemento constituinte da chave primária da tabela relacionada com aquela chave externa.

38 Integridade da informação numa base de dados relacional Uma chave externa, como sabemos, referencia uma entidade existente numa outra tabela (onde é chave primária). Por conseguinte, sempre que é introduzido um valor num campo que é chave externa de uma tabela, o sistema (SGBD ou aplicação) tem de certificar-se que esse valor existe na chave primária da tabela referenciada por aquela chave externa; caso contrário, a base de dados passaria a ter uma inconsistência ou uma falha de integridade referencial (ver exemplos das figuras 9 e 10).

39 Clientes CodCliente Nome Morada C101 ABC Porto C102 DEF Lisboa Artigos CodArtigo Artigo CodFornec Modem Scanner 102 C103 GHI Faro 1033 Teclado 102?? Encomendas N.º Encom. Data Encom. CodCliente CodArtigo Quantidade C C C C Fig 9 Exemplificação de violações da integridade referencial: 1 a introdução, na tabela Encomendas, de um cliente com o código C130 que não existe na tabela Clientes; 2 a introdução, na tabela Encomendas, de um artigo com o código 155, que não existe na tabela Artigos.

40 Clientes CodCliente Nome Morada C101 ABC Porto C102 DEF Lisboa C103 GHI Faro Artigos CodArtigo Artigo CodFornec Modem Scanner Teclado 102?? Encomendas N.º Encom. Data Encom. CodCliente CodArtigo Quantidade C C C Fig 10 Exemplificação de violações da integridade referencial: 1 a eliminação de um registo na tabela Clientes com o código C103, ficando uma ou mais referências a esse cliente na tabela Encomendas; 2 a alteração, na tabela Artigos, do artigo 1033 para 1035; na tabela Encomendas ficariam referências a um artigo (com o código 1033) não conforme com a tabela Artigos a que se refere.

41 Integridade da informação numa base de dados relacional Por outro lado, sempre que quisermos apagar ou alterar um registo numa tabela e esse registo estiver relacionado com registos de outra tabela, estamos perante uma outra possibilidade de violação da integridade referencial ficarmos com registos que referenciam um registo que deixou de existir. Vajamos, de exemplos concretos, alguns casos típicos de violação da integridade referencial.

42 Integridade da informação numa base de dados relacional 1 Na tabela Encomendas da figura 9, pretendemos introduzir um registo, em que o campo CodCliente tem o valor C130. Estamos perante um caso de violação da integridade referencial. O campo CodCliente é chave externa na tabela Encomendas e chave primária na tabela Clientes; ora, nesta última, não existe nenhum registo com o código C130; portanto, a informação que pretendíamos introduzir tem uma falha de integridade referencial.

43 Integridade da informação numa base de dados relacional 2 Na tabela Clientes da figura 10, pretendemos eliminar um registo correspondente ao artigo com o código C103. Se o fizermos, o que é que acontece aos registos da tabela Encomendas que dizem respeito a esse artigo? Se os mantivermos, estamos a criar uma falha de integridade referencial (a tabela Encomendas tem registos que referenciam artigos que não existem na respetiva tabela).

44 Integridade da informação numa base de dados relacional 3 Na tabela Artigos (figura 10), pretendemos alterar o artigo com o código 1033 para Também aqui desaparece um valor (1033) numa tabela (Artigos), enquanto numa outra tabela (Encomendas) continuam a existir registos que fazem referência a esse valor. O SGBD ou a aplicação que estiver a gerir a base de dados devem estar preparados para evitar estas situações em que a informação perde consistência ou integridade referencial, enviando mensagens ao utilizador que lhe permitam retificar a operação.