Independența datelor în baza de date relațională

Poate cineva să explice modul în care independența datelor este asigurată într-o bază de date relațională? Ce spune că nimic nu se va schimba pentru utilizator dacă structura bazei de date se modifică?

De exemplu, am relația R (și am creat o aplicație care folosește această relație) iar administratorul bazei de date decide să facă o descompunere a R la R1 și R2. Cum este asigurată inalterabilitatea aplicației pentru utilizatorul final?

0

4 răspunsuri

De exemplu, am relația R (și am creat aplicația care folosește această relație) și administratorul bazei de date dorește să facă o descompunere a R la R1 și R2. Cum este asigurată aplicabilitatea aplicației pentru utilizatorul final?

Administratorul ar trebui să creeze o vizualizare care să reprezinte R1 și R2 ca R originală.

0
adăugat

Întrebarea dvs. nu este formulată foarte clar. Nu văd relația dintre "independența datelor" și "inalterabilitatea aplicațiilor".

O structură relațională adecvată descompune datele în entități și relații. Ideea este că atunci când o valoare se schimbă, ea se schimbă numai într-un singur loc. Acesta este motivul din spatele diferitelor "forme normale" de date.

Majoritatea aplicațiilor utilizatorilor nu doresc să vadă datele într-o formă normalizată. Ei doresc să vadă datele într-o formă denormalizată, adesea cu multe domenii adunate pe o singură linie. În mod similar, o actualizare ar putea implica mai multe domenii în diferite entități, dar pentru un utilizator, este doar un singur lucru.

O bază de date relațională poate menține structura datelor și vă permite să combinați datele pentru puncte de vedere diferite. Nu are nimic de-a face cu al doilea punct. Aplicarea independenței (cred că acesta este un cuvânt mai bun decât "inalterabilitatea") depinde de modul în care este proiectată aplicația. O aplicație bine concepută are o interfață de programare a aplicațiilor bine concepute (cunoscută și ca API).

Se pare că o mulțime de dezvoltatori de baze de date consideră că structura fizică a datelor este suficient de bună ca API. Cu toate acestea, aceasta este adesea o decizie de proiectare proastă. Adesea, o decizie mai bună de proiectare este ca toate operațiile bazei de date să fie efectuate prin proceduri, vizualizări și funcții definite de utilizator. Cu alte cuvinte, nu actualizați direct un tabel. Creați o procedură stocată numită ceva usp_table_update care necesită câmpuri și actualizează tabelul.

Cu o astfel de structură, puteți modifica structura bazei de date și puteți întreține simultan aplicațiile utilizatorilor.

0
adăugat
Nu voi contesta termenii academici. Aveți o problemă cu răspunsul meu?
adăugat autor Gordon Linoff, sursa
Independența datelor este un concept relațional bazat pe DB și este puternic legat de inalterabilitatea aplicațiilor
adăugat autor Carlos Gavidia, sursa
Numai că întrebarea se referă la conceptele teoretice ale bazei de date pe care răspunsul dvs. nu le abordează. Pe de altă parte, sunt de acord cu majoritatea declarațiilor.
adăugat autor Carlos Gavidia, sursa

ceea ce spune că nimic nu se va schimba pentru utilizator în cazul în care baza de date   schimbări de structură?

Ei bine, structurile de baze de date se pot schimba din mai multe motive. La nivel înalt, văd două posibilități:

  1. motive de performanță/bază de date interne
  2. Regulile de afaceri/lumea în afara aplicației a fost modificată

@ 1: în acest caz, DBA a decis să schimbe o anumită structură pentru performanță sau ... În acest caz un strat suplimentar, de exemplu, folosind proceduri stocate, vizualizări etc. poate ajuta la "ascunderea" schimbării aplicației/utilizatorului . Sau un bun strat de date pe partea aplicației ar putea fi util.

@ 2: dacă lumea exterioară se modifică sau dacă se schimbă regulile afacerii dvs., NIMIC pe care le puteți face la nivelul bazei de date poate păstra acest lucru departe de utilizator. De exemplu, o companie care a utilizat întotdeauna doar o singură monedă în baza de date devine brusc internațională: în acest caz, baza dvs. de date trebuie adoptată pentru a sprijini o monedă multiplă și va necesita modificări serioase în baza de date și pentru utilizator.

0
adăugat
Foarte interesant, am o singură întrebare: @ 1 este ca programe de procedură în care o mare cantitate de variabile globale sunt utilizate de o mare cantitate de subprograme, nu face ca complexitatea bazei de date să fie comparată cu complexitatea proceselor timpurii software-uri?
adăugat autor Zack ISSER, sursa

M-am întrebat exact aceeași întrebare în timpul clasei mele de bază de date.

Conform celor 12 reguli Codd , există două tipuri de independență a datelor:

  • Physical Data Independence requires that changes at the physical level (like data structures) have no impact in the applications that consume the database. For example, let's say you decide to stop using a Hash Index in your table and decide to use a B-Tree Index instead: Your application that executes queries against this table doesn't have to change at all.
  • Logical Data Independence states that changes at the logical level (tables, columns, rows) will have no impact in the applications that access the database. As you already noticed, this feature is harder to implement that Physical Data Independence but there are still cases when this feature works. For example, if you add Tables, Columns or Rows to your current scheme the already working queries aren't affected at all.
0
adăugat