Qual è la differenza tra schema a 3 livelli e schema a 5 livelli?

Qual è la differenza tra schema a 3 livelli e schema a 5 livelli? Naturalmente, 2 livelli. :-)

La terminologia di schema a 3 livelli e schema a 5 livelli hanno alcune parole in comune solo per coincidenza. In realtà non hanno quasi nulla a che fare l'uno con l'altro. Uno non è un superinsieme dell'altro.

3 livelli di schema separano la memorizzazione fisica dei dati da uno schema concettuale dai metadati accessibili all'utente. Vedi la risposta di Bill Karwin a Qual è la differenza tra livello e schema nell'architettura ANSI-SPARC?

5 livello di schema si riferisce al modo in cui si può controllare l'accesso allo schema in un sistema di database federato. I termini provengono da una ricerca del 2003 pubblicata da Nayyer Masood della Bahauddin Zakariya University, e Barry Eaglestone dell'Università di Sheffield. Ecco un link al documento: http://majlis.fsktm.um.edu.my/document.aspx?FileName=268.pdf

Re il tuo commento:

...quali sono le differenze comparative (confrontando database distribuiti e sistemi di database centralizzati) tra questi?

Distinguiamo tra database federati e database centralizzati. Sto evitando i database distribuiti, perché un dato database può essere distribuito (cioè distribuito su più server) senza essere federato.

Un database federato, il soggetto dell'articolo di Masood/Eaglestone, è descritto come:

Un sistema multidatabase mira a fornire l'accesso ai dati da più database disparati, chiamati database componenti, in modo trasparente. Una particolare architettura di un sistema multidatabase è un sistema di database federato (FDBS) proposto in [21]. Un FDBS fornisce la possibilità di definire diverse federazioni di diversi sottoinsiemi di schemi di database che partecipano/si uniscono all'FDBS.

Quando si dice "database disparati", significa che i dati sono gestiti da diversi software, e probabilmente diversi server. Per esempio, potreste avere alcuni dati gestiti in Microsoft SQL Server su un server, e altri dati gestiti in MySQL sul proprio server, e anche alcuni dati in MongoDB da qualche altra parte. Ma si vuole la possibilità per un'applicazione di interrogare qualsiasi dato in modo trasparente come se fosse in un unico database.

L'idea di un database federato sarebbe un software che sa dove vive ogni sottoinsieme di dati, e può interpretare la query della vostra applicazione e tradurla in query multiple per ogni rispettivo DBMS, recuperare i risultati e riassemblarli in un unico set di risultati, schermando la vostra applicazione da qualsiasi conoscenza che i dati sono stati sparsi in giro.

Un database non federato è il contrario: i dati sono gestiti da un'implementazione del DBMS. La vostra applicazione può interrogare direttamente il DBMS e ottenere un risultato da quel database, ma è limitata a quell'unico database. Questo è sia positivo che negativo. Si tende ad avere più efficienza nel fare le query, e questo è un bene per la maggior parte delle applicazioni, che usano comunque un solo database. Ma se avete dati sparsi su diversi database, può rendere la codifica dell'applicazione più complessa perché dovete interrogare diversi database individualmente, e combinare i risultati nel codice dell'applicazione.

Nota che il concetto di un database federato non ha mai preso piede, e non è usato ampiamente. Le ragioni includono:

• È costoso sviluppare il software che sa come riscrivere le query su misura per più marche di DBMS.
• È costoso eseguire il software dei dati federati. È probabile che abbia cattive prestazioni in fase di esecuzione, perché le query generate dalla macchina tendono ad essere meno efficienti delle query codificate da un umano.
• Solve un problema che la maggior parte delle applicazioni non ha bisogno di risolvere. Però è un interessante articolo di informatica.

L'architettura orientata al servizio è la soluzione più popolare in questi giorni per i database disparati. Questo comporta la scrittura di applicazioni più semplici che possono interrogare le loro rispettive fonti di dati e restituire i risultati attraverso un'API REST. Questo dà sia l'opportunità di assemblare i dati in un formato uniforme (per esempio, JSON è popolare), e permette anche ad ogni servizio di scrivere codice efficiente su misura per il suo rispettivo DBMS.

La soluzione SOA scala bene sia per lo sviluppo che per il runtime.