Baixe o app para aproveitar ainda mais
Prévia do material em texto
Aula 05 Banco de Dados I - UNIGRAN CARDINALIDADE Prezado(a) aluno(a), Na aula que ora se inicia, iremos construir conhecimentos e receber algumas dicas para apresentação da cardinalidadae, além disso, aprender como ter um bom relacionamento entre os dados apresentados. Lembre-se de que, entre os estudos de uma aula e outra, é importante realizar intervalos e sempre que for ingerir alimentos, opte por lanches leves, como frutas ou cereais, pois alimentos muito pesados podem causar sonolência. Aproveitamos a oportunidade para reiterar que sua participação é muito importante e estamos preparados para ensinar e aprender com seus avanços... Bom trabalho! Objetivos de aprendizagem Ao término desta aula, você será capaz de: • identificar e interpretar, em linhas gerais, os tipos de relacionamento entre os dados; • reconhecer alguns conceitos básicos de chave como: Chave Primária e a Chave Estrangeira; • apontar as etapas e refletir sobre a integridade forte e fraca e a integridade referencial. 73 Banco de Dados I - UNIGRAN Seções de estudo • Seção 1 - Definição. • Seção 2 - Autorrelacionamento. • Seção 3 - Chaves. • Seção 4 - Entidade forte e entidade fraca. • Seção 5 - Integridade referencial. Seção 1 – Defi nição Veremos, nesta aula, que a definição é a quantidade de relacionamentos das ocorrências de uma entidade com outra, os relacionamentos entre duas entidades e o número de ocorrências de uma entidade que está associada, com ocorrências de outras entidades. A cardinalidade indica a forma com que uma entidade participa do relacionamento (ELMASRI; NAVATHE, 2005). Nesse contexto, o Grau de relacionamento ou cardinalidade pode ser classificado como: relacionamento de um para um (1:1), relacionamento de um para muitos (1:n) e relacionamento de muitos para muitos (n:n). Vamos conhecê-los! 1.1 Relacionamento de Um Para Um (1:1) Quando cada ocorrência de uma entidade se relaciona com apenas uma ocorrência da outra entidade. No exemplo da Figura 5.1, somente um homem se relaciona com uma mulher, somente um elemento de uma tabela pode se relacionar com um elemento da outra tabela. Dessa forma, precisamos ler o relacionamento nos dois sentidos, na qual ele se efetua. Ademais, lemos que a entidade Homem está casada apenas com uma mulher e uma mulher está casada apenas com um homem (MACHADO; ABREU, 2009). Para iniciar nossas refl exões, nesta primeira seção da Aula 5, vamos aprofundar nossos conhecimentos sobre a importância da cardinalidade, além de conferir a importância da relação dos dados para a criação de um banco de dados. Bons estudos! 74 Banco de Dados I - UNIGRAN Os autores exortam, ainda, que os analistas de sistemas podem cometer erros na construção de modelos de dados, tomando conclusões apressadas sobre cardinalidade. Vejamos como as cardinalidades podem ser representadas no relacionamento 1:1: 1.2 Relacionamento de Um Para Muitos (1:n) Quando cada ocorrência de uma entidade se relaciona com várias ocorrências da outra entidade, sendo este o mais comum no mundo real. Segundo Machado e Abreu (2009), quando um elemento da entidade 01 pode relacionar-se com muitos elementos da entidade 02, mas cada elemento da entidade 02 pode somente se relacionar com um elemento da entidade 01. Vamos estudar o caso do mundo real: temos a entidade Aluno onde estão armazenados todos os alunos matriculados em uma escola. Essa entidade precisa se relacionar com as notas fornecidas pelos professores. Essas notas estão armazenadas na entidade Notas, mas cada aluno geralmente possui quatro notas bimestrais. Logo, o grau de relacionamento entre essas duas entidades não pode ser de 1:1, pois cada aluno possui quatro notas. Atenção!!! Precisamos tomar cuidado em sempre verifi car os dois lados da leitura do relacionamento, para verifi car qual é o grau necessário desse relacionamento. FONTE: MACHADO, Felipe Nery Rodrigues; ABREU, Mauricio Pereira. Projeto de banco de dados: uma visão prática. 16 ed. São Paulo: Érica, 2009. Figura 5.1 Representação das cardinalidades em 1:1. 75 Banco de Dados I - UNIGRAN Esse relacionamento então se torna diferenciado, pois um aluno poderá ter na entidade Nota uma nota em cada bimestre. Mas cada nota está relacionada somente a um aluno. Alguns autores definem que para se saber se um relacionamento é do tipo um para muitos (1:n) o sentido oposto da leitura apresenta obrigatoriamente o grau um para um (1:1). Observe a cardinalidade representada em 1:n: 1.3 Relacionamento de Muitos Para Muitos (n:n) O n:n acontece quando cada ocorrência de uma entidade se relaciona com várias ocorrências da outra entidade e vice-versa (MACHADO; ABREU, 2009). Vamos estudar dois casos do mundo real: a) em um sistema de uma escola temos uma entidade Aluno que cursa várias disciplinas, e uma entidade Disciplina (língua portuguesa, Inglês, Introdução). Nesse exemplo, um aluno estuda várias disciplinas e uma disciplina é cursada por vários alunos. b) temos ainda outra entidade, o Funcionário, que tem cadastrado todos os funcionários de uma empresa, e está relacionado com outra entidade, o Projeto. Em uma empresa um funcionário pode estar envolvido em um ou dois projetos diferentes, bem como também pode não estar envolvido em nenhum projeto. FONTE: MACHADO, Felipe Nery Rodrigues; ABREU, Mauricio Pereira. Projeto de banco de dados: uma visão prática. 16 ed. São Paulo: Érica, 2009. Figura 5.2 Representação das cardinalidades em 1:n. 76 Banco de Dados I - UNIGRAN No caso do segundo exemplo, o mesmo pode-se dizer da entidade Projeto, que pode ter um ou dois funcionários envolvidos em cada projeto e também pode existir um projeto sem nenhum Funcionário. Vejamos a representação: Seção 2 – Autorrelacionamento É o relacionamento entre ocorrências da mesma entidade. No exemplo abaixo temos a entidade Empregado, em que estão cadastrados todos os empregados de uma empresa. Cada empregado está relacionado com o chefe/líder do setor onde trabalha, mas o chefe/líder do setor também é um empregado. Por isso, um empregado pode estar relacionado com outro empregado. Nesse caso, ele é ao mesmo tempo um empregado e também um chefe de setor (MACHADO; ABREU, 2009). Segundo Elmasri e Navathep (2005), podemos afirmar que um autorrelacionamento são representações de estruturas de hierarquia na maioria das vezes. Logo, entre os empregados existe uma relação de hierarquia. FONTE: MACHADO, Felipe Nery Rodrigues; ABREU, Mauricio Pereira. Projeto de banco de dados: uma visão prática. 16 ed. São Paulo: Érica, 2009. Compreendendo a defi nição de cardinalidade, passemos ao estudo sobre o autorrelacionamento. Figura 5.3 Representação das cardinalidades em n:n. 77 Banco de Dados I - UNIGRAN Vale salientar que alguns empregados são chefes de setor de outros, que por sua vez são subordinados a um outro chefe de setor ou gerente: Seção 3 – Chaves Uma resposta adequada para este questionamento seria que uma chave, neste contexto, trata-se de “uma coluna da tabela que permite, para cada linha, identificar essa linha (caso seja a chave primária), ou relacionar com outra tabela no caso da chave estrangeira” (DICIONÁRIO SENSAGENT, 2013). A chave é, portanto, um conjunto de um ou mais atributos que tomados coletivamente nos possibilita identificar unicamente uma entidade no conjunto-entidade. Nesse sentido, a questão fundamental do projeto de chaves é diminuir ao máximo os efeitos de redundâncias. Assim, a mudança dos valores de campos FONTE: MACHADO, Felipe Nery Rodrigues; ABREU, Mauricio Pereira. Projeto de banco de dados: uma visão prática. 16 ed. São Paulo: Érica, 2009. ? ? O que são chaves em base de dados? ? VOCÊ SABIA Nenhum atributo que parƟ cipe da chave de um conjunto-enƟdade precisa aceitar valores nulos ou em branco. Figura 5.4 Autorrelacionamento. 78 Banco de Dados I - UNIGRAN constituintes da chave primária ou a exclusão de uma entidade de um conjunto de entidades pode levar a problemas de integridade referencial. A chave indica um atributo (campo) dentro da entidade (tabela) e terá um valor que não poderá ser repetido dentro dos registros (instâncias). Ele será um valor único, que não poderá ter outro igual (MACHADO; ABREU, 2009). As chaves podem ser formadas por um ou mais atributos, dependendo da necessidade da identificação da entidade. Existem dois tipos de chaves: Chave Primária e Chave Estrangeira. 3.1. Chave Primária As chaves primárias automaticamente definem que os valores das colunas (campos, atributos) em questão estarão presentes em um índice, ocorrendo somente uma única vez. Também conhecida como Chave Principal, serve para identificar cada instância (tupla) dentro da entidade. Toda entidade tem que ter obrigatoriamente uma Chave Primária (HEUSER, 2001). A chave serve para dar unicidade a um registro (tupla, linha). É ela que diferencia uma tupla de todas as outras. Todos os campos da entidade, exceto a chave, podem se repetir, ou seja, em uma entidade somente pode existir uma chave primária. A chave primária, de acordo com Heulser (2001), trata-se de uma entidade formada por um ou mais atributos. Quando é formada por apenas um atributo, chamamos de chave simples, quando é formada por dois ou mais atributos, chamamos de chave composta. Vejamos, a seguir, dois exemplos de uma entidade (tabela) representada fisicamente em um banco de dados, na qual teremos uma tabela com uma chave primária simples e outro com uma chave primária composta. 3.1.1 Exemplo 01- Chave Primária Nesse primeiro exemplo temos a Table (tabela – entidade) Cidade, que faz parte de um Banco de Dados chamado Renassul. Notem que a chave primária dessa tabela é PK (Primary Key – Chave primária) CÓDIGO e ela não pode ter Fique antenado! Na internet você pode encontrar inúmeros sites sobre o tema em estudo. Sugiro que realize buscas uƟ lizando termos como: ‘projetar um site’, ‘etapas do projeto de um site’ entre outras, como palavras-chave e procure ler alguns arƟ gos em relação ao conteúdo. Com os conhecimentos que está adquirindo, cada vez mais você se será capaz de superar o senso comum sobre as informações disponibilizadas nos diferentes meios de comunicação e uƟ lizá-las como fontes de pesquisa, sempre que considerar que se trata de conhecimentos úteis! 79 Banco de Dados I - UNIGRAN um valor nulo (null), pois não podemos ter nenhum cadastro de cidade com o código vazio (HEUSER, 2001). Vale salientar que através dessa chave primária CÓDIGO que nós teremos o índice dessa tabela que nos ajudará a consultar e pesquisar os dados cadastrados nela. Veja: 3.1.2 Exemplo 02 – Chave primária Já no segundo exemplo temos a Table (tabela – entidade) Cliente, que faz parte de um Banco de dados Chamado Renassul. Notem que a chave primária dessa tabela é PK (Primary Key – Chave primária) CODCLI e ela não pode ter um valor nulo (null). Nesse caso, também o analista de sistemas definiu o atributo (campo) NOME como não podendo ter o valor nulo (null). É importante observar que esse detalhe é importante, pois embora a chave primária CODCLI por definição não possa ter o valor nulo, ou seja, não permite que o usuário deixe de digitar um valor para esse atributo (campo). Ademais, pode acontecer que sem querer ele deixe o nome do aluno em branco, e salve (grave) o registro da tabela. Nesse caso, como foi definido o atributo (campo) NOME Not Null (valor não pode ser nulo) ele não deixará que o usuário grave esse registro sem algum valor (HEUSER, 2001). Observe: FONTE: Acervo pessoal. FONTE: Acervo pessoal. Figura 5.5 Exemplo 1: chave primária. Figura 5.6 Exemplo 2: chave primária. 80 Banco de Dados I - UNIGRAN Como é possível observar, na estrutura existente, deve-se escolher um ou mais campos que irão compor a chave. Para isso, é necessário observar algumas regras para a criação da chave da entidade, que valem para qualquer entidade do sistema (HEUSER, 2001): a) Os atributos de uma chave nunca podem ficar vazios, são sempre obrigatórios; b) Uma chave não pode nunca se repetir. Se ela serve para dar unicidade a registro (linha, tupla), significa que não podem existir na mesma entidade duas chaves com conteúdos iguais. 5.1.3 Exemplo 03 – Chave primária composta Finalmente, no exemplo 03 temos a Table (tabela – entidade) ITEMCLIENTE, que faz parte de um Banco de dados Chamado Renassul. Notem que a chave primária dessa tabela é PK (Primary Key – Chave primária) CODCLI E CONSULTA e elas não podem ter um valor nulo (null). Nesse caso temos essa tabela relacionada com a entidade CLIENTE, em que o código do cliente será acrescido nessa tabela e junto com a consulta. Nesse caso temos uma chave primária composta (HEUSER, 2001). Observem ainda que temos a definição Primary key com o nome PK_ ITEM CLIENTE que contém On Field (campos) CODCLI, CONSULTA e temos em seguida o arquivo de índice criado nessa tabela o PK_ITEMCLIENTE e a última informação será a forma que esses arquivos de índice classificará as informações Index Sorting – Ascending (ascendente). FONTE: Acervo pessoal. Após o estudo dos três exemplos de chave primária, propormos avançaremos sobre o estudo da chave estrangeira. Figura 5.7 Exemplo 3: chave primária composta. 81 Banco de Dados I - UNIGRAN 3.2 Chave Estrangeira As chaves estrangeiras (Foreign Key) automaticamente definem que os valores das colunas (campos, atributos) em questão estarão presentes em um índice da tabela que se refere. Este tipo de chave, também conhecida como Chave secundária é usada sempre que há um relacionamento entre entidades. A chave estrangeira numa entidade sempre se referencia a uma chave principal em outra entidade, ou seja, o relacionamento é feito sempre através da chave principal. Se uma chave principal de uma entidade for composta, a chave estrangeira que se relaciona com ela em outra entidade também será composta, ou seja, elas devem ser compatíveis para a relação (HEUSER, 2001). A chave estrangeira (Foreign Key), diferente da chave principal, não serve para identificar as tuplas da entidade, mas sim para relacionar as tuplas de uma entidade com as tuplas de outra. Um relacionamento com chave estrangeira é importantíssimo por manter a integridade do banco de dados. Como no exemplo 03, visto anteriormente, nosso banco de Dados Renassul, tem a tabela CLIENTES e CIDADE. A TABELA CIDADE tem o campo CÓDIGO que representa o identificador da cidade cadastrada. Se nós criarmos um relacionamento de PK x FK entre as colunas CÓDIGO E CODCID das duas tabelas teremos então assegurado a integridade de nosso banco. Isso é provado pelo seguinte fato: se o nosso usuário tentar inserir na tabela CLIENTE um Código que não há na tabela CIDADE será automaticamente acusado um erro de integridade: FONTE: Acervo pessoal. Figura 5.8 Exemplo 4: chave estrangeira. 82 Banco de Dados I - UNIGRAN Vejamos, agora, como seria descrito em um DER as tabelas vistas nesses exemplos que utilizamos entre as entidades (tabelas) CLIENTES, CIDADE, ITEMCLIENTE: Seção 4 – Entidade Forte e Entidade Fraca Uma entidade pode ser classificada como Forte e Fraca. Vamos entendê-las melhor! Entidade forte: a) sua existência não depende de outra entidade; b) sua chave é composta apenas por atributos próprios; Entidade fraca: a) sua existência depende de outra entidade; b) não possui atributos próprios suficientes para montar a chave; Para melhor compreensão sobre estas entidades, observe a imagem a seguir: FONTE: Acervo pessoal. Figura 5.9 Tabelas dos exemplos1, 2, 3 e 4 escritas no DER. 83 Banco de Dados I - UNIGRAN As ocorrências da entidade NOTA DO ALUNO só poderão existir no sistema se houver o ALUNO correspondente. Seção 5 – Integridade Referencial Quando a ocorrência de uma entidade (fraca) depende da ocorrência de outra entidade (forte), ocorre a dependência existencial. Como foi visto anteriormente, uma entidade fraca depende de outra entidade para existir (ELMASRI; NAVATHE, 2005). É o mesmo que dizer que uma ocorrência de NOTA DO ALUNO só existirá se houver o ALUNO, ou seja, não pode existir uma nota lançada para um aluno se este aluno não estiver cadastrado no sistema. Se por um descuido um aluno for excluído do sistema, as notas desse aluno ficariam “perdidas”, sem relacionamento com ALUNO, ou seja, haveria uma quebra da integridade. FONTE: MACHADO, Felipe Nery Rodrigues; ABREU, Mauricio Pereira. Projeto de banco de dados: uma visão prática. 16 ed. São Paulo: Érica, 2009. Ao fi nal de cada seção, é importante que lembrar-se de que em caso de dúvidas, ou de difi culdades, você não precisa se “afogar”! Procure entrar em contato conosco por meio do ambiente virtual e seguir as dicas de pesquisa recomendadas ao longo da aula. Sempre que possível, sugerimos que procure se adiantar na realização das aƟ vidades que representam uma parte da avaliação conƟ nuada da disciplina, uma vez que tal estratégica poderá ser interessante para ajuda-lo(a) a se organizar e a ganhar tempo para responde-las de forma mais saƟ sfatória! Pense nisso... Passemos, a seguir, ao estudo da Integridade Referencial! Figura 5.10 Entidade forte e fraca. 84 Banco de Dados I - UNIGRAN Retomando a conversa inicial • Seção 1 – Definição Na primeira seção da Aula 5, vimos que cardinalidade pode ser entendida como a quantidade de relacionamentos das ocorrências de uma entidade com outra no BD. Os relacionamentos entre duas entidades, o número de ocorrências de uma entidade que está associada, com ocorrências de outras entidades. Ademais, entendemos o Relacionamento de um para um (1:1), de um para muitos (1:n). • Seção 2 – Autorrelacionamento Já na segunda seção, compreendemos que o autorrelacionamento é o relacionamento entre ocorrências da mesma entidade. Conferimos ainda um exemplo de entidade Empregado, em que foram cadastrados todos os empregados de uma determinada empresa. • Seção 3 – Chaves Nesta terceira seção, compreendemos que a chave é um conjunto de um ou mais atributos que tomados coletivamente nos possibilita identificar unicamente uma entidade no conjunto-entidade. Desse modo, nenhum atributo que participe da chave de um conjunto- entidade precisa aceitar valores nulos ou em branco. Conhecemos a Chave Primária e a Chave Estrangeira. FONTE: MACHADO, Felipe Nery Rodrigues; ABREU, Mauricio Pereira. Projeto de banco de dados: uma visão prática. 16 ed. São Paulo: Érica, 2009. Retomar conhecimentos é fundamental para sedimentar o processo de aprendizagem. Aproveite esta oportunidade! Figura 5.11 Integridade referencial. 85 Banco de Dados I - UNIGRAN • Seção 4 – Entidade Forte e Entidade Fraca Na quarta seção compreendemos que uma entidade pode ser classificada como Forte e Fraca. • Seção 5 – Integridade Referencial Por fim, entendemos que quando a ocorrência de uma entidade (fraca) depende da ocorrência de outra entidade (forte), ocorre a dependência existencial e, em seguida, vimos a importância da integridade. Sugestões de leituras, sites e vídeo Leituras CARVALHO, I. C. L.; KANISKI, A. L. A sociedade do conhecimento e o acesso à informação: para que e para quem? Revista Ciência da Informação, Brasília, v. 29, n. 3, p. 33-39, set./dez. 2000. CASTELLS, M. A Sociedade em Rede: a era informação − economia, sociedade e cultura. Paz e Terra, 2007. CERRI, M. L. ERP: Um estudo dobre estratégias de implantação. Dissertação (Mestrado) – Escola de Engenharia de São Carlos, Universidade de São Paulo, São Paulo, 2004. CRUZ, T. Sistemas de informações gerenciais: tecnologia de informação e a empresa do século XXI. São Paulo: Atlas, 1995. DAVENPORT, T. H. Ecologia da informação: por que só a tecnologia não basta para o sucesso na era da informação. São Paulo: Futura, 1998. ELMASRI, R.; NAVATHE, S. B. Sistema de Banco de Dados. Tradução de Marília Guimarães Pinheiro et al. São Paulo: Pearson Education, 2005. EPSTEIN, I. Teoria da Informação. São Paulo: Ática S.A., 1986. FERREIRA, S. M. S. P. Redes eletrônicas e necessidades de informação: abordagem do sense-making para estudo de comportamento de usuários do Instituto de Física da USP. 1995. Tese (Doutorado em Ciências da Comunicação) - Escola de Comunicações e Artes, Universidade de São Paulo, São Paulo, 1995. Viu como a cardinalidade é interessante e desafi adora? Para encerrar os estudos e sedimentar a aprendizagem, é fundamental que conƟ nue pesquisando sobre o tema, acesse o ambiente virtual e realize as aƟ vidades propostas para a Aula 3! 86 Banco de Dados I - UNIGRAN GIL, A. C. Como Elaborar Projetos de Pesquisa. São Paulo: Atlas, 1987. HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Editora Sagra Luzzatto, 2001. LE COADIC, Y-F. A Ciência da Informação. Brasília: Briquet de Lemos, 1996. LÉVY, P. As Tecnologias da Inteligência. Rio de Janeiro: Editora 34, 1993. MACHADO, Felipe Nery Rodrigues; ABREU, Mauricio Pereira. Projeto de banco de dados: uma visão prática. 16 ed. São Paulo: Érica, 2009. MATTOS, J. R.; GUIMARÃES, L. S. Gestão da tecnologia da informação: uma abordagem prática. São Paulo: Saraiva, 2005. MCGARRY, K. J. O contexto dinâmico da informação: uma análise introdutória. Brasília: Briquet de Lemos, 1999. ______. Da documentação à informação: um contexto em evolução. Lisboa: Editorial Presença; Associação Portuguesa de Bibliotecários, Arquivistas e Documentalistas, 1984. MCGEE. J; PRUSAK, L. Gerenciamento estratégico da informação: aumente a competitividade e a efi ciência de sua empresa utilizando a informação como ferramenta estratégica. Rio de Janeiro: Campus, 1994. MIRANDA, R. C. da R. O uso da informação na formulação de ações estratégicas pelas empresas. Revista Ciência da Informação, Brasília, v.28, n.3, 1999/set./dez. p. 284-290. MORESI, E. A. D. Delineando o valor do sistema de informação de uma organização. Revista Ciência da Informação. Brasília, v. 29, n. 1, 2000/jan/abr. p. 14-24. O’BRIEN, J. A. Sistemas de informação e as decisões gerenciais na era da Internet. 4ª. Tiragem. São Paulo: Saraiva, 2004. OLIVEIRA, A. O Valor da Informação. In: Dossier Informação. Revista Pequena e Média Empresa, n.12. 3ª. série. 1994. PAIM, I. NEMHY, R. M. Q; GUIMARÃES, C. G. Problematização do conceito “Qualidade” da informação. Perspectiva Ciência da Informação. v. 1, n. 1, p. 111-119, jan./jun. 1996. PATTON, M. Q. Qualitative Research and Evaluation Methods. London: Sage Publications, 2002. POLIZELLI , D, L; OSAKI, A. M. Sociedade da informação: os desafi os da era da colaboração e da gestão do conhecimento. São Paulo: Saraiva, 2008. REZENDE, D. A; ABREU. A. F. de. Tecnologia da Informação: Aplicada a Sistemas de Informação Empresariais. 3. Ed. São Paulo: Atlas, 2003. SARACEVIC, Tefko. Information Science. Journal of the American Society for Information Science, v. 50, n. 12, 1999. 87 Banco de Dados I - UNIGRAN SHANNON, C. E; WEAVER, W. The mathematical theory of communication. Urbana: University of Illinois, 1949. ZEMAN, J. Signifi cado fi losófi co da noção de informação. In: O conceito de informação na Ciência Contemporânea. Rio de Janeiro: Paz e Terra, 1970. Sites • COHEN, M. Alguns aspectos do uso da informação na economia da informação. Revista Ciência da Informação, Brasília, v. 31, n. 3, set./dez. 2002. 26-36 p. Disponível em: <http://revista.ibict.br/index.php/ciinf/article/view/144/124>.Acesso em: 26 set. 2013. • DICIONÁRIO SENSAGENT. Chave (banco de dados). Disponível em: <http:// dicionario.sensagent.com/chave+banco+de+dados/pt-pt/>. Acesso em: 25 nov. 2013. • KLABIN. Centro de Documentação e Memória da Klabin. Disponível em: <http://www.klabin.com.br/pt-br/klabin/centroMemoria.aspx>. Acesso em: 26 set. 2013. • NEHMY, R. M. Q; PAIM, I. A desconstrução do conceito de "qualidade da informação". Ciência da Informação. Brasília, vol. 27, no. 1, 1998. Disponível em: <http://www.scielo.br/scielo.php?script=sci_arttext&pid =S0100-19651998000100005>. Acesso em: 26 set. 2013. • PESTANA, M. C et al. Desafi os da sociedade do conhecimento e gestão de pessoas em sistemas de informação. Revista Ciência da Informação, Brasília, v. 32, n. 2, p. 77-84, maio/ago. 2003. Disponível em: <revista.ibict.br/index.php/ ciinf/article/download/121/102>. Acesso em: 26 set. 2013. • SETZER, V. W. Dado, informação, conhecimento e competência. Disponível em: <http://www.dgz.org.br/dez99/Art_01.htm>. Acesso em: 26 set. 2013. Vídeo • YOU TUBE. Aula 05: Modelo ER (esclarecimento cardinalidade). Disponível em: <https://www.youtube.com/watch?v=1CIwIawZzNY >. Acesso em: 26 set. 2013. 88
Compartilhar