Qual é a diferença entre o esquema de 3 níveis e 5 níveis?

Qual é a diferença entre o esquema de 3 níveis e 5 níveis? Claro, 2 níveis. :-)

A terminologia do esquema de 3 níveis e do esquema de 5 níveis tem algumas palavras em comum apenas por coincidência. Eles realmente não têm quase nada a ver um com o outro. Um não é um super conjunto do outro.

esquema de 3 níveis separa o armazenamento físico de dados de um esquema conceitual de metadados acessíveis ao usuário. Veja a resposta de Bill Karwin' Qual é a diferença entre Nível e Esquema na arquitetura ANSI-SPARC?

esquema de nível 5 refere-se à forma como se pode controlar o acesso ao esquema em um sistema de banco de dados federado. Os termos vêm de um artigo de pesquisa de 2003 publicado por Nayyer Masood da Universidade Bahauddin Zakariya, e Barry Eaglestone da Universidade de Sheffield. Aqui está um link para o artigo: http://majlis.fsktm.um.edu.my/document.aspx?FileName=268.pdf

Re o seu comentário:

...quais são as diferenças comparativas (comparando bases de dados distribuídas e sistemas de bases de dados centralizadas) entre estes?

Distinguimos entre bases de dados federadas e bases de dados centralizadas. Estou evitando bases de dados distribuídas, porque uma determinada base de dados pode ser distribuída (isto é, espalhada por múltiplos servidores) sem ser federada.

Uma base de dados federada, o assunto do trabalho Masood/Eaglestone, é descrita como:

Um sistema de bases de dados multidisciplinares visa fornecer o acesso aos dados de bases de dados múltiplas e díspares, chamadas bases de dados componentes, de uma forma transparente. Uma arquitetura particular de um sistema multibases de dados é um sistema federado de bases de dados (FDBS) proposto em [21]. Um FDBS fornece a facilidade de definir diferentes federações de diferentes subconjuntos de esquemas de bases de dados participando/juntando ao FDBS.

Quando dizem "bases de dados díspares", isso significa que os dados são geridos por diferentes softwares, e provavelmente diferentes servidores. Por exemplo, você pode ter alguns dados gerenciados no Microsoft SQL Server em um servidor, e outros dados gerenciados no MySQL em seu próprio servidor, e até mesmo alguns dados no MongoDB em outro lugar. Mas você quer a capacidade de uma aplicação para consultar qualquer dado de forma transparente como se estivesse em um banco de dados.

A idéia de um banco de dados federado seria algum software que sabe onde cada subconjunto de dados vive, e pode interpretar suas aplicações consultando e traduzindo-as em múltiplas consultas para cada SGBD respectivo, buscar os resultados e remontá-los em um conjunto de resultados, protegendo sua aplicação de qualquer conhecimento de que os dados estavam espalhados por aí.

Um banco de dados não federado é o oposto: os dados são gerenciados por uma implementação do SGBD. A sua aplicação pode consultar o SGBD directamente e obter um resultado a partir dessa base de dados, mas está limitada a essa única base de dados. Isto é tanto um positivo como um negativo. Você tende a obter mais eficiência fazendo consultas, e isso é bom para a maioria das aplicações, que usam apenas uma base de dados de qualquer forma. Mas se você tiver dados espalhados por bancos de dados díspares, isso pode tornar a codificação da aplicação mais complexa porque você tem que consultar vários bancos de dados individualmente, e combinar os resultados no código da aplicação.

Nota que o conceito de um banco de dados federado nunca foi realmente capturado, e não é usado amplamente. As razões incluem:

• É caro desenvolver o software que sabe como reescrever consultas adaptadas a múltiplas marcas de SGBD.
• É caro executar o software de dados federados. É provável que tenha mau desempenho em tempo de execução, porque as consultas geradas por máquinas tendem a ser menos eficientes do que as consultas codificadas por um humano.
• li> Resolve um problema que a maioria das aplicações não precisa ser resolvido. No entanto, a arquitetura orientada a serviços é a solução mais popular hoje em dia para bases de dados díspares. Isso envolve escrever aplicações mais simples que podem cada uma consultar suas respectivas fontes de dados e retornar os resultados através de uma API REST. Isso dá tanto a oportunidade de montar dados em um formato uniforme (por exemplo, JSON é popular), e também permite que cada serviço escreva um código eficiente sob medida para seu respectivo SGBD.

  A solução SOA é bem dimensionada tanto para desenvolvimento quanto para tempo de execução.