Modelo de Dados e Arquitetura de Banco de Dados PDF - Católica EAD

Modelo de Dados e Arquitetura do Sistema de Banco de Dados ©2018 Copyright ©Católica EAD. Ensino a distância (EAD) com a Apresentação  Fonte: http://www.baixaki.com.br/imagens/66381/8177.jpg  Desde 1950, quando o computador foi utilizado para o armazenamento e processamento de grand...

Modelo de Dados e Arquitetura do Sistema de Banco de Dados ©2018 Copyright ©Católica EAD. Ensino a distância (EAD) com a Apresentação  Fonte: http://www.baixaki.com.br/imagens/66381/8177.jpg  Desde 1950, quando o computador foi utilizado para o armazenamento e processamento de grandes massas de dados em ambiente empresarial, percebeu-se a necessidade de ampliar suas capacidades computacionais por meio de: aumento de memória de armazenamento temporário (RAM ). sistemas de armazenamento permanente de dados (discos rígidos). processadores mais velozes. modelos de dados mais eficientes e robustos, com arquiteturas de softwares específicas para gerenciamento de dados. métodos mais abstratos e integrados de representação do conhecimento que possibilite o desenvolvimento de sistemas computacionais.  ambientes e linguagens de desenvolvimento de sistemas de aplicações de usuários mais abrangentes e com recursos para implementar a representação do conhecimento modelada. meios físicos e lógicos mais velozes de distribuição dos dados para organizações complexas, com soluções de hardware e software. Assim, deu-se início a uma crescente pesquisa em diversas áreas do conhecimento computacional, visando, entre elas, tornar o computador uma máquina capaz de armazenar e processar dados no maior volume possível e com aplicações que fornecessem respostas às inquietudes rotineiras dos utilizadores. Surgiram, então, os primeiros sistemas de armazenamento de dados, que possibilitaram o armazenamento de dados por meio de sistemas de aplicação de usuário desenvolvidos de modo pouco natural. As inconsistências desses sistemas proporcionaram a percepção de que se deveria subir um nível de abstração na representação da realidade a ser computável. A primeira tentativa de solução surgiu com a proposição dos sistemas de lista invertida que, mesmo tendo solucionado algumas dessas inconsistências, ainda apresentavam dificuldade de representação do conhecimento de modo natural, pois eram construídos com visão física das regras de negócio a ser modelado. Assim, surgiram os Modelos de Dados, os quais veremos a seguir! ©2018 Copyright ©Católica EAD. Ensino a distância (EAD) com a Conteúdo  Modelos de Dados A identificação de diversas inconsistências nos sistemas, tal como a necessidade de um modo melhor para descrever relações entre os dados armazenados, e uma maneira mais fácil e rápida de pesquisar os dados, induziram à necessidade de que se deveria ampliar o nível de abstração na representação da realidade a ser automatizada, e esse passo deu origem aos Modelos de Dados. Segundo Date  (2004), um modelo de dados é uma definição abstrata, autônoma e lógica dos objetos, operadores e outros elementos que, juntos, constituem a máquina abstrata com a qual os usuários interagem. Os objetos, nos permitem modelar a estrutura dos dados. Os operadores, nos permitem modelar seu comportamento. Podemos, então, distinguir de modo útil o modelo de sua implementação: uma implementação de um determinado modelo de dados é uma representação física sobre uma máquina real dos componentes da máquina abstrata que juntos constituem esse modelo. Corroborando com Date, segundo Elmasri  (2011), modelos de dados podem ser definidos como conjunto de conceitos que podem ser usados para descrever a estrutura de um banco de dados. O Modelo de Dados fornece significado necessário para permitir essa abstração, ou seja, a representação de um banco de dados de forma textual ou gráfica. Por estrutura de um banco de dados pode-se entender os tipos de dados, relacionamentos e restrições, que devem suportar os dados. Note que hoje em dia, a maioria dos modelos de dados também inclui uma série de operações básicas para a recuperação e atualizações no banco de dados. Categorias dos Modelos de Dados É possível categorizar os modelos de dados quanto os tipos de conceitos utilizados para descrever a estrutura do banco de dados, tal como os de alto nível ou modelo de dados conceituais, que descrevem os dados como os usuários os percebem, e de baixo nível ou modelo de dados físico, que descrevem os detalhes de como os dados serão armazenados. Segundo Elmasri (2011), entre os dois modelos apresentados anteriormente, existe uma classe de modelos de dados representacionais (ou de implementação), que oferecem conceitos que podem ser entendidos pelos usuários finais, mas não excessivamente distantes da forma como os dados estão organizados dentro do computador. As categorias citadas serão apresentadas com mais detalhes no decorrer da disciplina, dado que elas fazem parte das etapas de um projeto de banco de dados. Os modelos de dados representacionais ou de implementação são os mais utilizados nos SGDBs  comerciais tradicionais. Ele inclui o popular modelo de dados entidade relacionamento (MER), bem como os modelos de dados legados: Modelo Hierárquico (MH) e Modelo de Rede (MRede), também chamados de Sistemas CODASYL ou Sistemas DBTG  da CODASYL , que escreveu a primeira especificação-padrão de banco de dados, chamada Relatório CODASYL DBTG 1971; Modelo relacional Estendido (MRE ou Relacional-Objeto ou Pós-Relacional) e, finalmente, o Modelo Orientado a Objeto (MOO), os quais são descritos a seguir. Modelo Hierárquico Foi o primeiro modelo de dados formal e surgiu na década de 60. Considera que as estruturas de dados eram o reflexo de sua utilização em uma organização e sendo esta hierárquica, os modelos de solução eram compostos por estruturas hierarquizadas. Os diagramas da solução consideram as estruturas de dados hierárquicas e seus dados possuíam subordinação top-down, tais como: vendedor – clientes - vendas – produtos. Essas estruturas somente permitem a navegação top-down, o que limita sobremaneira as buscas de dados. Os dados nesses SGBD são gravados em uma coleção de estruturas em árvores e são classificados em "pai" e "filho". Somente os pais possuem os endereços dos dados dos filhos. Assim, para se localizar os dados de vendas, precisa-se saber o endereço do cliente. A programação utiliza os ponteiros de maneira explícita para poder associar os dados gravados. A mesma utilização de ponteiros é feita para as consultas. Modelo de Rede – Sistemas CODASYL Inicialmente, foi apresentado no relatório do grupo de trabalho CODASYL, em 1971, sendo chamado modelo DBTG. Foi revisado em 1978 e 1981 e apresenta uma evolução do Modelo Hierárquico para resolver suas limitações. Permite a criação de estruturas mais flexíveis, em que os dados podem ser associados entre si, por exemplo: cliente/vendas; e vendas/cliente. Assim, pode-se navegar entre essas estruturas considerando qualquer uma delas. Os dados são organizados em vários tipos de registros e o relacionamento dos registros pai e filho são explícitos. Em seu diagrama de estrutura de dados, os tipos de registros são organizados na forma de um grafo arbitrário, enquanto no  diagrama de estrutura de árvore os tipos de registros são organizados na forma de árvore com raiz. A navegação ficou mais flexível, porém, ainda se utilizam os ponteiros explicitamente. Figura 1 – Modelo de Rede onte: Elmasri,2005 Modelo Relacional Foi introduzido por Codd  (1970); sua utilização comercial, no entanto, se deu por volta do ano de 1978. Comparando-o com o modelo de dados hierárquico e o modelo de redes, é o mais simples, uma vez que apresenta uma estrutura de dados mais uniforme e menos física; é também o mais formalizado, pois foi inteiramente baseado na teoria dos conjuntos. É um conjunto de dados armazenados em tabelas bidimensionais que possuem linhas e colunas. Tem como características permitir a criação de estruturas de dados organizadas em tabelas que possuem relacionamento entre si. Também possuem uma linguagem nativa para utilização do banco de dados SQL . A fundamentação conceitual do Modelo Relacional (MR) deu origem a uma reformulação na mentalidade computadorizada comercial, impulsionando o ambiente de pesquisas em sistemas de armazenamento e tratamento de dados, capacidades de processamento de hardware e proposição de modelos abstratos para representação do conhecimento, como os modelos semânticos de dados. Entretanto, novas aplicações, limitadas por restrições impostas pelo MR, fizeram surgir necessidades de bancos de dados que suportassem novos tipos de dados. "Essas novas aplicações de bancos de dados não foram consideradas nos anos 70, quando muitos dos sistemas de bancos de dados comerciais foram projetados" (SILBERSCHATZ , 1999, p.250). Exemplos: Sistemas de Suporte à Decisão; CAD ; CAM ; CASE  – Engenharia de Software Apoiada por Computador; Bancos de Dados Espaciais; Banco de Dados Multimídia; Bancos de Dados Móveis (Mobile Database); Resgate (Retrieval) de Informações; Office Information System (OIS) (Resgates de Informações Distribuídas); Banco de Dados Hipertexto. Modelo Objeto-Relacional Também designado como Modelo de Dados Relacional Estendido (MRE) e, no original, é RM/T , tem como finalidade ser mais representativo em semântica e construções de modelagens do que os tradicionais. Isso porque, além de fixar as características da modelagem tradicional, os modelos relacionais estendidos incorporaram as características do modelo orientado a objetos também. A seguir, apresentamos algumas diferenças imediatas identificadas, conforme compara Date (2004), entre os modelos relacionais e os estendidos: O MRE não diferencia entidades e relacionamentos como o MR tradicional. O MRE define mais precisamente os aspectos estruturais e de integridade a serem utilizados do que o MR tradicional. O RM/T possui as suas próprias definições e operações a serem utilizadas, mas utiliza também as operações definidas e utilizadas pelo MR. Modelo Orientado a Objeto Segundo Silberschatz (1999, p.7), esses modelos:  [...] são usados na descrição de dados no nível lógico e de visões. São caracterizados por dispor de recursos de estruturação bem mais flexíveis e por viabilizar a especificação explícita das restrições dos dados. Existem vári os modelos nessa categoria, e outros ainda estão por surgir. Alguns são amplamente conhecidos, como: Modelo Entidade-Relacionamento; Modelo Orientado a Objetos; Modelo Semântico de Dados; e Modelo Funcional de Dados. Desses modelos, somente interessa ao escopo deste item conceitual, o Modelo Orientado a Objetos. Modelo de Dados Orientado a Objetos Segundo Silberschatz (1999, p.8), esses modelos têm a seguinte caracterização: tem por base um conjunto de objetos.  um objeto contém valores armazenados em variáveis de instâncias dentro do objeto. um objeto contém um conjunto de códigos que o operam, chamados métodos (permite que clientes solicitem serviços a um objeto por meio de uma mensagem). Até esse ponto, você estudou o histórico dos Modelos de Dados, que permitiu a compreensão de sua evolução histórica. Agora, podemos entrar com mais propriedade na Arquitetura do Sistema de Banco de Dados. Arquitetura do Sistema de Banco de Dados A arquitetura a ser esclarecida aqui é basicamente idêntica à apresentada pelo ANSI/SPARC (Study Group on Data Base Management System), mas sem seguir todo o seu rigor. Níveis de Arquitetura A arquitetura ANSI/SPARC divide o Sistema de Banco de Dados em três níveis: interno, conceitual e externo, conforme figura a seguir: Figura 2 - Arquitetura Detalhada do Sistema de Banco de Dados Fonte: Date, 2004 Observe o detalhamento sobre tais aspectos: O nível externo – É o nível do usuário individual. Esse usuário qualquer pode ser ou programador de aplicações ou um usuário final com qualquer grau de sofisticação. Cada usuário possui uma linguagem apropriada para fazer a intercomunicação. Para um programador de aplicações, essa linguagem será uma linguagem convencional, assim como Java ou C++. O nível conceitual – É uma representação abstrata, definida por meio de um esquema, de todo o conteúdo de informações do banco de dados, em comparação com o modo como os dados são armazenados fisicamente. Também se diferencia pela maneira como o usuário vê a informação. O nível interno – É o nível mais próximo do meio de armazenamento físico, sendo aquele que se ocupa do modo como os dados são fisicamente armazenados dentro do sistema. A visão interna ainda está separada do nível físico, pois ela não lida com registros físicos, também chamados blocos ou páginas, nem com quaisquer considerações específicas de dispositivos, bem como tamanhos de cilindros ou trilhas. Mapeamento conceitual/interno – Define a correspondência entre a visão conceitual e o banco de dados armazenado, especificando o modo como os registros e campos conceituais são representados no nível interno. Em caso de alteração da estrutura do banco de dados armazenado, esse mapeamento deverá ser modificado de acordo com as alterações, com a finalidade de manter o esquema conceitual inalterado, sendo essas modificações de responsabilidade do DBA  ou algumas vezes do SGBD. Mapeamento externo/conceitual – Define a correspondência entre uma visão externa específica e a visão conceitual, não diferindo muito do mapeamento conceitual/interno, no tocante à necessidade de modificações para adequar o mapeamento em caso de uma modificação. Exemplo: a alteração do nome de um campo não pode afetar a visão de um usuário ao banco de dados, assim como a alteração da forma com que se armazenam os dados não modifica a maneira de o usuário ver o banco de dados. Catálogo – Segundo Date (2004) é o lugar em que todos os esquemas (externo, conceitual e interno) e todos os mapeamentos correspondentes (externo/conceitual, conceitual/interno,  externo/externo) são mantidos. O catálogo contém informações detalhadas com relação aos diversos objetos de interesse do próprio sistema (índices, usuários, restrições de integridade, restrições de segurança e assim por diante). É também conhecido como descritores , dicionário de dados , metadados , repositórios de dados ou enciclopédias de dados . O catálogo pode ser definido como "dados sobre dados", ou seja, descrições de outros objetos do sistema, ao invés de simples "dados em bruto". O SGBD Segundo Date (2004), o SGBD é o software que trata de todo acesso ao banco de dados, o que ocorre da seguinte forma: 1. Um usuário faz um pedido de acesso usando uma determinada sublinguagem de dados (geralmente a SQL). 2. O SGBD intercepta o pedido e o analisa. 3. O SGBD, por sua vez, inspeciona o esquema externo (ou as versões objeto desse  esquema) para esse usuário, o mapeamento externo/conceitual correspondente, o esquema conceitual, o mapeamento conceitual/interno e a definição do banco de dados armazenado. 4. O SGBD executa as operações necessárias sobre o banco de dados armazenado. As figuras 3 e 4 apresentam o detalhamento dessas funções. Figura 3 – Estrutura do SGBD Fonte: Date, 2004 Figura 4 – Módulos Componentes de um SGBD e suas Interações te: Elmasri, 2005 Para que o SGBD trate de todo acesso ao banco de dados, ele provê as seguintes funções: Definição de dados – Deve ser capaz de aceitar definições de dados em formato fonte e convertê-lo para o formato de objeto apropriado. Para isso, um SGBD deve incluir um processador ou compilador de DDL . Além disso, deve ser capaz de entender os objetos. Manipulação de dados – Deve ser capaz de lidar com requisições do tipo busca, atualização ou exclusão. Inclui um processamento ou compilador DML  e, em geral, essas requisições podem ser: Planejadas – Aquelas previstas pelo DBA, nas quais geralmente são feitos ajustes para atender com um desempenho melhor. Exemplo: requisições operacionais. Não planejadas – Também conhecidas como consulta ad-hoc, são aquelas não planejadas e, por isso, possuem um desempenho geralmente um pouco mais baixo. Otimização e execução – As requisições DML são processadas por um otimizador que determina a maneira mais eficiente de implementar a requisição. Em seguida, são executadas sob controle do gerenciador em tempo de execução. Segurança e integridade dos dados – Deve monitorar as requisições de usuário e  rejeitar toda tentativa de violar as restrições de segurança ou integridade. Recuperação de dado e concorrência – Deve-se manter um gerenciador de transação para impor certos controles de recuperação e concorrência. Dicionário de dados – O SGBD deve fornecer uma função de dicionário de dados que pode ser considerado como um banco de dados para o sistema ou um banco isolado. Nele, estão contidos os metadados, que são "dados sobre dados". Desempenho – O SGBD deve realizar todas as funções acima descritas da forma mais eficiente possível. Nesse momento, é importante diferenciarmos o gerenciador de arquivos como componente do sistema operacional básico que administra arquivos armazenados. Portanto, pode-se dizer que ele está mais próximo do disco do que do SGBD. No entanto, ao contrário do SGBD, deve-se observar que os gerenciadores de arquivo: não têm conhecimento da estrutura interna dos registros armazenados e, por isso, não  podem lidar com requisições que dependam de um conhecimento dessa estrutura. em geral, fornecem pouco ou nenhum suporte para controles de recuperação, concorrência e integridade. não comportam verdadeiramente um conceito de dicionário de dados . proporcionam muito menos independência de dados que o SGBD. em geral, seus arquivos estão "integrados" ou "compartilhados" no mesmo sentido que o banco de dados, mas são primitivos de algum usuário ou de alguma aplicação específica. Blocos ou Páginas de Dados Para Date (2004), bloco ou página de dados é a unidade de entrada e saída (E/S) que representa a quantidade de dados transferidos entre o meio de armazenamento secundário e a memória principal em uma única operação de E/S. Os SGBD Relacionais atuam nesse conceito, ou seja, seus dados são armazenados em estruturas lógicas denominadas tabelas, que possuem linhas e colunas. Os dados de uma tabela são armazenados considerando os seguintes critérios: as linhas da tabela são armazenadas em uma página e se essa for maior que a capacidade da página, outra será criada para armazená-la. cada página de dados somente deve possuir dados de uma tabela. Arquitetura Física Centralizada Observe o esquema abaixo, que sintetiza a ideia de uma arquitetura centralizada: Figura 5 – Arquitetura Física Centralizada Fonte: Elmasri, 2005 Arquitetura Cliente/Servidor Segundo Date (2004), o principal objetivo dessa arquitetura é o de fornecer suporte ao desenvolvimento e à execução de aplicações de banco de dados e, sob um ponto de vista de alto nível. Essa arquitetura está dividida em duas partes, sendo uma delas o servidor (back end) e a outra o cliente (front end): O servidor é o próprio SGBD. Ele admite todas as funções básicas de um SGBD. Em outras palavras, o termo servidor é apenas um outro termo para SGBD. Os clientes são as diversas aplicações executadas com base no SGBD, que podem ser escritas por usuários ou aplicações internas (built-in, ou seja, aplicações fornecidas pelo fabricante do SGBD). As figuras 6, 7 e 8, a seguir, apresentam esquemas de arquiteturas cliente/servidor. Figura 6 – Arquitetura Lógica Cliente/Servidor de Duas Camadas Fonte: Elmasri, 2005 Para Refletir  Um Servidor de Banco de Dados pode ser utilizado por uma filial, mesmo estando em outro continente? Quais são as implicações do Servidor de Banco de Dados estar fora da rede local? Figura 7 – Arquitetura Física cliente/servidor de duas Camadas Fonte: Elmasri, 2005 Figura 8 – Arquitetura Lógica Cliente/Servidor de três Camadas Fonte: Elmasri, 2005 Outro aspecto importante, quando tratamos de SGBD, é pensarmos nos utilitários, programas projetados para auxiliar o DBA com diversas tarefas administrativas. Segundo Date (2004) esses são alguns exemplos de utilitários: Rotinas de carga – Cria a versão inicial do banco de dados a partir de um ou mais arquivos do sistema operacional.  Rotinas de descarga/recarga (ou dump/restore) – Descarrega o banco de dados ou parte dele para o meio de armazenamento de back-up e recarrega dados dessas cópias de back-up. Rotinas de reorganização – Arruma novamente os dados no banco de dados armazenados por vários motivos, entre eles desempenho. Rotinas de estatísticas – Calcula estatísticas de desempenho (tamanhos de arquivos e distribuição de valores, contagens de E/S). Rotinas de análise – Analisa as estatísticas acima. Para Refletir  Atualmente, qual a importância de se manter os dados estruturados e separados da aplicação? Concluindo...  Nesta aula, você pôde estudar os Modelo de Dados e a Arquitetura de um Banco de Dados. Na próxima aula trataremos o principal modelo de dados, o Relacional, utilizando largamente nos dias atuais. Até lá e bons estudos! ©2018 Copyright ©Católica EAD. Ensino a distância (EAD) com a Na Prática  "Prezado(a) estudante, Esta seção é composta por atividades que objetivam consolidar a sua aprendizagem quanto aos conteúdos estudados e discutidos. Caso alguma dessas atividades seja avaliativa, seu (sua) professor (a) indicará no Plano de Ensino e lhe orientará quanto aos critérios e formas de apresentação e de envio." Bom Trabalho! Atividade 01   De fato, com o passar do tempo, houve avanços nos modelos de dados até chegarmos ao Modelo Relacional, que não é o último modelo da evolução, mas certamente é o mais utilizado, dado suas características. Diante do exposto, monte uma apresentação em slides descrevendo, de forma breve, as principais características dos modelos de dados supracitados. Atividade 02   Pesquise e identifique os motivos pelos quais o Modelo Relacional foi bem aceito pela comunidade e quais vantagens ele tem em relação aos outros modelos de dados. Atividade 03   Dado que a arquitetura ANSI/SPARC divide um sistema de Bando de Dados nos níveis: Interno, Conceitual e Externo, esclareça resumidamente a função de cada um deles. ©2018 Copyright ©Católica EAD. Ensino a distância (EAD) com a Saiba Mais  Para ampliar seu conhecimento a respeito desse assunto, veja abaixo a(s) sugestão(ões) do professor: Para conhecer um pouco mais sobre o modelo de dados hierárquico, veja o texto: "Um pouco sobre Banco de Dados Hierárquico ". ©2018 Copyright ©Católica EAD. Ensino a distância (EAD) com a Referências  Bibliografia Básica ELMASRI S. B.; NAVATHE R. E. Sistemas de banco de dados. 4. ed. São Paulo: Pearson - Addison Wesley Brasil, 2005. ELMASRI, Ramez; NAVATHE, Sham. Sistemas de banco de dados. 6. ed. São Paulo: Pearson - Addison Wesley, 2011 HEUSER, C. A. Projeto de banco de dados. 5. ed. Rio Grande do Sul: Sagra Luzzato, Séria Informática da UFRGS, 2004. OLIVEIRA, C. H.P. SQL – curso prático. São  Paulo: Novatec, 2002. SILBERSCHATZ, A., KORTH, H. F.; SUDARSHAN S. Sistemas de banco de dados. São Paulo: McGraw-Hill, 1999. Bibliografia Complementar BATINI, C., CERI, S., NAVATHE, S. Conceptual database design: an entity-relationship approach. The Benjamin/Cummings Publishing Co. Inc, 1992. BERTINO, Eliza & MARTINO, Lorenzo, Object- oriented database Systems – concepts and architectures. Addison-Wesley, 1993. BOURBAKI, Nicolas. Théorie des ensembles, de la collection éléments de mathématique. Paris: Hermann, 1970. CHEN, Peter Pin-Shan. The entity-relationship model-toward a unified view of data. Ed. ACM Transactions on Database Systems. Vol.1, No. 1, Massachusetts Institute of Technology (MIT), 1976. CHEN(a), Peter Pin-Shan. Modelagem de dados: a abordagem entidade-relacionamento para projeto lógico. São Paulo: Makron, 1990. CODD, E. F., A relational model of data for large shared data banks: Ed. Communications of the ACM (CACM), vol.13 nº6, pp. 377-387, Junho de 1970. CODD, E. F., Extending the database relational model to capture more meaning: Ed. Transactions on Database Systems (ACM TODS), vol.4, nº4, pp. 397-434, dezembro de 1979. CODD, E. F., Is your DBMS really relational? Ed. ComputerWorld, 14 de outubro de 1985. CODD, E. F., Does your DBMS run by the rules? Ed. ComputerWorld, 21 de outubro de 1985. DATE, C. J. Introdução a sistemas de banco de dados – Tradução da 8. Edição Americana, Rio de Janeiro: Elsevier, 2004. ENGLES, R. W. A tutorial on data-base organization. Report TR-00.2004, International Business Machines Corp., System Development Division, Poughkeepsie, New York (1970). MARTIN, James. Princípios de análise e projeto baseados em objetos. Rio de Janeiro: Campus, 1994. MARTIN, James. Computer data-base organization. 2. ed. Englewood Cliffs, New Jersey: Prentice-Hall, Inc., 1977. MORIN, Edgard. O método 3. O conhecimento do conhecimento. Porto Alegre: Sulina, 1999. p.1-40. NASSU, Eugênio e SETZER, Waldemar. Banco de dados orientados a objetos. Edgard Blücher Ltda, 1999. ÖZSU, M. Tamer; VALDURIEZ, Patrick. Princípios de sistemas de banco de dados distribuídos. Rio de Janeiro: Campus, 2001. SETZER, Valdemar W. Banco de dados: conceitos, modelos, gerenciadores, projeto lógico, projeto físico. - 3.ed. rev. - São Paulo: Edgard Blucher, 1989.p.1-40. WATSON, Richard T. Data management - databases and organizations. 2. ed. John Willey & Sons, 1999.