Weryfikacja danych zapisanych w bazie
Jerzy
problem dotyczy pewny krytycznych danych, od których wymagane jest 100%
pewności, że nie zostały przypadkiem/celowo zmodyfikowane. O ile celową
ingerencję można (wstępnie) wykluczyć, o tyle przypadkowe popsucie
danych nie. W przypadku uszkodzenia bazy wolę stracić część danych niż
mieć chociaż cień wątpliwości czy naprawa bazy nie popsuła danych.
Jest kilka relacji pomiędzy zbiorami, ale zasadniczo problem można
zawęzić do dwóch przypadków:
1. określenie czy dane zapisane do tabeli są na pewno tymi samymi
danymi, które z tabeli odczytujemy.
2. określenie, czy rekord odczytany z tabeli detail, na pewno jest
poprawnie powiązany z właściwym rekordem z master.
Problem dotyczy tylko wybranych pól w tabelach. Nie muszę /wręcz nie
chcę/ robić tego sprawdzenia na całym rekordzie z tabeli.
Pierwsze co mi wpadło do głowy, to trzymanie sum kontrolnych:
Ad.1. dodajemy nadmiarowe pole z sumą kontrolną, która jest wyliczana wg
niezmiennego schematu (liczby i daty trzeba jakoś ustandaryzować)
Ad.2. dwie wersje
- trzymamy osobną sumę kontrolną od całego złączenia detail+master
- trzymamy w detail sumę kontrolną z master
Oba przypadki wymagają przeliczenia sumy kontrolnej w detail, w
przypadku gdy zmienią się dane z master - to nie jest problemem.
Drugie rozwiązanie to dublowanie danych. Dane zapisujemy w bliźniaczych
tabelach a każdy odczyt danych wymusza weryfikowanie danych z
bliźniaczej tabeli. Warunkiem jest zachowanie tych samych ID, albo
upraszczając, trzymanie ID z głównych tabel w ich zdublowanych
odpowiednikach.
Problem jest na razie ogólny, nie dotyczy żądnego konkretnego systemu
DB. No, chyba że jakiś SZBD ma wbudowane mechanizmy do wspierania takich
wymagań.
Gdyby ktoś miał jakiś pomysł, albo doświadczenie w takim temacie, to
zapraszam do dyskusji. Może istnieją jakieś wzorce opisujące takie
przypadki?
--
Pozdrawiam
J.B.
Jacek Czerwinski
>
> problem dotyczy pewny krytycznych danych, od których wymagane jest 100%
> pewności, że nie zostały przypadkiem/celowo zmodyfikowane. O ile celową
> ingerencję można (wstępnie) wykluczyć, o tyle przypadkowe popsucie
> danych nie. W przypadku uszkodzenia bazy wolę stracić część danych niż
> mieć chociaż cień wątpliwości czy naprawa bazy nie popsuła danych.
> Problem jest na razie ogólny, nie dotyczy żądnego konkretnego systemu
> DB. No, chyba że jakiś SZBD ma wbudowane mechanizmy do wspierania takich
> wymagań.
>
> Gdyby ktoś miał jakiś pomysł, albo doświadczenie w takim temacie, to
> zapraszam do dyskusji. Może istnieją jakieś wzorce opisujące takie
> przypadki?
>
tylko dublowanie, ale właśnie relacyjność zakłada swobodę. Np.
hurtownie, czyli jak cel jest archiwalny, są pozbawione relacji na rzecz
ogromnych rekordów.
b) jak rzecz jest krytycznie ważna, robi się nie 2 warstwowo, tylko 3
(serwer aplikacyjny).
Pewność, tajność itd na 2 warstwach nie jest do utrzymania na dłuższy
dystans. Jedna z aplikacji jaką sprzedawałem, miała nieudokumentowane
tabele i kodowane pola (w części zarządzajacej użytkownikami), ale jak
sie wywracał setup, ujawniał w komunikatach o błedach wszystkie tajne
skrypty tworzące obiekty w bazie ;)
c) sumy kontrolne spotykałem nie tak rzadko w 'oddolnych' rozwiązaniach,
nie spotkałem się w teorią to wspierającą w odniesieniu do baz.
d) więcej elementu 'hurtownianego' ? Tabel write only, historycznych itd?
Jerzy
>>
> a) wydaje si�, �e to odchodzi o "wyk�adowego" modelu relacyjnego (nie
> tylko dublowanie, ale w�a�nie relacyjno�� zak�ada swobod�. Np.
> hurtownie, czyli jak cel jest archiwalny, sďż˝ pozbawione relacji na rzecz
> ogromnych rekord�w.
Nie jest problemem odej�cie od wzorcowego modelu relacyjnego (istnieje
taki w praktyce?). Cel nie jest stricte archiwalny. Co majďż˝ do tego
hurtownie danych? Nie za bardzo rozumiem co chcesz mi przekazaďż˝.
> b) jak rzecz jest krytycznie wa�na, robi si� nie 2 warstwowo, tylko 3
> (serwer aplikacyjny).
Architektura 3 warstwowa IMO nie zapewnia zak�adanych postulat�w, a
2-warstwowa ich nie wyklucza.
> Pewno��, tajno��
Tajno�� nie jest nadrz�dna, zreszt� o niej nie wspomina�em.
> itd na 2 warstwach nie jest do utrzymania na d�u�szy
> dystans.
Uzasadnij. Tak teoretycznie to mo�na sobie d�ugu dyskutowa�.
> Jedna z aplikacji jak� sprzedawa�em, mia�a nieudokumentowane
> tabele i kodowane pola (w cz�ci zarz�dzajacej u�ytkownikami), ale jak
> sie wywraca� setup, ujawnia� w komunikatach o b�edach wszystkie tajne
> skrypty tworz�ce obiekty w bazie ;)
Co to ma do rzeczy?
> c) sumy kontrolne spotyka�em nie tak rzadko w 'oddolnych' rozwi�zaniach,
> nie spotka�em si� w teori� to wspieraj�c� w odniesieniu do baz.
Do czego odnosi�y si� te sumy i jaki mia�y cel? Do rekordu, relacji,
wybranego pola?
> d) wi�cej elementu 'hurtownianego' ? Tabel write only, historycznych itd?
Nie do ko�ca o to chodzi. Zostawmy hurtownie danych w spokoju.
Podsumowuj�c, nie za bardzo wiem co mi chcia�e� przekaza�. W kontek�cie
zadanego pytania nie odnajduj� tutaj �adnej odpowiedzi. Podej�ewam, �e
jestem na du�o ni�szym poziomie i po prostu nie rozumiem, wi�c je�eli
mo�esz, to rozwi� troch� my�l albo (co lepsze) ode�lij mnie do
konkretnej literatury. Ch�tnie doczytam, tylko na razie nie wiem czego
szukaďż˝.
--
Pozdrawiam
J.B.
Jacek Czerwinski
> W dniu 2011-09-07 13:01, Jacek Czerwinski pisze:
>>>
>> d) wi�cej elementu 'hurtownianego' ? Tabel write only, historycznych itd?
> Nie do ko�ca o to chodzi. Zostawmy hurtownie danych w spokoju.
>
> Podsumowuj�c, nie za bardzo wiem co mi chcia�e� przekaza�.
Tylko tyle, �e
1. wali� sporo danych (danych g�ownych, nie sum) do dodatkowych tabel, z
odpowiednimi grantami :insert+, update-, delete-
Kosztowne, prymitywne, brutalne, dok�adne
Te chcia�em zilustrowa� hurtowni�.
2. Sumy kontrolne owszem, je�li obawa jest o przypadkowe zmiany, ale nie
utrzyma si� je�li z�o�liwe.
Sławomir Szyszło
<jerzybrzuh.p...@gmail.com> wklepaďż˝(-a):
>Pierwsze co mi wpad�o do g�owy, to trzymanie sum kontrolnych:
>Ad.1. dodajemy nadmiarowe pole z sum� kontroln�, kt�ra jest wyliczana wg
>niezmiennego schematu (liczby i daty trzeba jakoďż˝ ustandaryzowaďż˝)
>Ad.2. dwie wersje
>- trzymamy osobn� sum� kontroln� od ca�ego z��czenia detail+master
>- trzymamy w detail sumďż˝ kontrolnďż˝ z master
>Oba przypadki wymagajďż˝ przeliczenia sumy kontrolnej w detail, w
>przypadku gdy zmieniďż˝ siďż˝ dane z master - to nie jest problemem.
Dobra, masz metodďż˝ wykrywania zmian. Ale co z nimi zrobisz jak znajdziesz
r�nic�? Przecie� suma kontrolna raczej nie umo�liwi odtworzenia danych.
Druga sprawa - jak odr�nisz zapis celowy od niecelowej zmiany? Czy dane w bazie
majďż˝ byďż˝ zapisywane tylko raz, a potem tylko odczytywane?
A najlepiej to przedstaw jaki masz problem, zamiast proponowania od razu
rozwi�za�. Przed czym/kim chcesz si� zabezpieczy�, jakiego rodzaju to baza i
aplikacja itd.
--
S�awomir Szysz�o
Primus inter FAQires & Grand Inquisitor no.0 of pl.comp.bazy-danych
FAQ pl.comp.bazy-danych http://www.dbf.pl/faq/
Archiwum http://groups.google.com/groups?group=pl.comp.bazy-danych
Jerzy
> Dobra, masz metodďż˝ wykrywania zmian. Ale co z nimi zrobisz jak znajdziesz
> r�nic�? Przecie� suma kontrolna raczej nie umo�liwi odtworzenia danych.
Utrata danych nie jest problemem. Je�eli widz� korupcj� danych, to je
usuwam bo je�eli dane zgin� to nic wielkiego si� nie stanie. Istotne
jest to, �e je�eli mam dane, to musz� mie� 100% pewno��, �e s� poprawne.
> Druga sprawa - jak odr�nisz zapis celowy od niecelowej zmiany? Czy dane w bazie
> majďż˝ byďż˝ zapisywane tylko raz, a potem tylko odczytywane?
Zak�adam, �e polityka dost�pu do danych obroni si� przed celow� zmian�.
Mo�e inaczej - nikt nie ma z�ych intencji, system jest odseparowany od
internetu, wi�c wchodzi jedynie fizyczne/si�owe w�amanie. Pomi�my taki
przypadek.
> A najlepiej to przedstaw jaki masz problem, zamiast proponowania od razu
> rozwi�za�. Przed czym/kim chcesz si� zabezpieczy�, jakiego rodzaju to baza i
> aplikacja itd.
S� to wyniki bardzo specyficznych i trudnych pomiar�w. Na podstawie
wynik�w b�d� podejmowane decyzje - proste decyzje, czyli wynik X ->
decyzja A, Wynik Y -> decyzja B, itd. Wyniki wykonanego pomiaru mogďż˝ byďż˝
nieu�ywane przez np 3 lata. Dlatego po 3 latach musi by� pewno�� 100%,
�e dane przez te 3 lata nie zosta�y uszkodzone.
Brak danych oznacza konieczno�� wykonania eksperymentu i dopiero mamy
wynik. Czas jest istotny, ale du�o mniej warty od b��dnie podj�tej
decyzji. Czas przelicza si� na pieni�dze, natomiast b��dna decyzja mo�e
powodowa� odpowiedzialno�� karn�.
--
Pozdrawiam
J.B.
Jacek Czerwinski
> Są to wyniki bardzo specyficznych i trudnych pomiarów.
Dlaczego mówisz, że nie jest to projekt typu "archiwalnego". Pomiar się
stał, dnia tego a tego, być może wymagał jakiś etapów pośrednich
(opracowania), ale potem jest const na wieki wieków amen.
najpierw sam się nastawiasz na zmiany starych danych, potem stwierdzasz,
że masz z tym problem. To prawdziwy "pomiar" jaki zna inżynieria. czy
raczej badania marketingowe które wiadomo jak mają wyjść?
Mam swoją dewizę, że system informatyczny wychodzi lepiej, jak
odwzorowuje prawdę, niż jak jego celem jest fikcja (w finansach,
produkcji itd). Jak ktoś, kto powiedział, że "ma słaba pamięć i dlatego
woli mówic prawdę"
Piotr M Kuć
> W dniu 2011-09-07 18:53, Sławomir Szyszło pisze:
>> Dobra, masz metodę wykrywania zmian. Ale co z nimi zrobisz jak znajdziesz
>> różnicę? Przecież suma kontrolna raczej nie umożliwi odtworzenia danych.
>
> Utrata danych nie jest problemem. Jeżeli widzę korupcję danych, to je
> usuwam bo jeżeli dane zginą to nic wielkiego się nie stanie. Istotne
> jest to, że jeżeli mam dane, to muszę mieć 100% pewność, że są poprawne.
>
>> Druga sprawa - jak odróżnisz zapis celowy od niecelowej zmiany? Czy dane w bazie
>> mają być zapisywane tylko raz, a potem tylko odczytywane?
>
> Zakładam, że polityka dostępu do danych obroni się przed celową zmianą.
> Może inaczej - nikt nie ma złych intencji, system jest odseparowany od
> internetu, więc wchodzi jedynie fizyczne/siłowe włamanie. Pomińmy taki
>
>> A najlepiej to przedstaw jaki masz problem, zamiast proponowania od razu
>> aplikacja itd.
>
> Są to wyniki bardzo specyficznych i trudnych pomiarów. Na podstawie
> wyników będą podejmowane decyzje - proste decyzje, czyli wynik X ->
> decyzja A, Wynik Y -> decyzja B, itd. Wyniki wykonanego pomiaru mogą być
> nieużywane przez np 3 lata. Dlatego po 3 latach musi być pewność 100%,
> że dane przez te 3 lata nie zostały uszkodzone.
> Brak danych oznacza konieczność wykonania eksperymentu i dopiero mamy
> wynik. Czas jest istotny, ale dużo mniej warty od błędnie podjętej
> decyzji. Czas przelicza się na pieniądze, natomiast błędna decyzja może
> powodować odpowiedzialność karną.
Reasumując chcesz pozwolić na wstawianie i oglądanie danych,
ale zabronić modyfikowania. Możesz to osiągnąć poprzez separację
użytkowników bazodanowych od tego który jest włascicielem
tabel z danymi, sterując uprawnieniami. Poniżej masz przykład,
dwa schematy DANE oraz WIDOK. Użytkownik WIDOK widzi i może wstawiać
rekordy do tabeli DANE.AQQ, ale nie może ich modyfikować.
C:\>sqlplus DANE/haslo@BAZA
SQL*Plus: Release 10.1.0.4.2 - Production on Wed Sep 7 21:55:14 2011
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Release 10.2.0.4.0 - 64bit Production
SQL> create table AQQ(id number, val varchar2(100));
Table created.
SQL> GRANT SELECT ON DANE.AQQ TO WIDOK;
Grant succeeded.
SQL> GRANT INSERT ON DANE.AQQ TO WIDOK;
Grant succeeded.
SQL> connect WIDOK/haslo@BAZA
Connected.
SQL> select * from DANE.AQQ;
no rows selected
SQL> insert into DANE.AQQ values (1, 'A');
1 row created.
SQL> update DANE.AQQ set val = 'B' where id = 2;
update DANE.AQQ set val = 'B' where id = 2
*
ERROR at line 1:
ORA-01031: insufficient privileges
SQL> insert into DANE.AQQ values (2, 'A');
1 row created.
SQL> select * from DANE.AQQ;
ID
----------
VAL
-----------------------------
1
A
2
A
--
Pozdrawiam, Piotr.Kuc-(szympans)-kuciak.net
Piotr Kuć
Jerzy
> ale zabronić modyfikowania.
Uproszczony model tak wygląda, ale opracowanie wyników jest kilku
etapowe. Już na etapie wyników pośrednich muszę zapewnić deklarowaną
poprawność danych, więc widzisz, że nie tędy droga. Oczywiście finalny
wynik można potraktować jako niezmienny, ale tak jak pisałem powyżej,
jest to wniosek a nie założenie.
> Możesz to osiągnąć poprzez separację
> użytkowników bazodanowych od tego który jest włascicielem
> tabel z danymi,
(jakiekolwiek, nie wnikajmy jakie) danych nie zostanie tutaj wykryte.
> sterując uprawnieniami. Poniżej masz przykład,
--
Pozdrawiam
J.B.
Jerzy
> W dniu 2011-09-07 19:08, Jerzy pisze:
> Dlaczego m�wisz, �e nie jest to projekt typu "archiwalnego". Pomiar si�
> sta�, dnia tego a tego, by� mo�e wymaga� jaki� etap�w po�rednich
> (opracowania), ale potem jest const na wieki wiek�w amen.
Ale co to zmienia? Co to wnosi do meritum? Ok, uznajmy, �e wykonany i
opracowany pomiar jest archiwalny. Co nam to daje w kontek�cie
zapewnienia, �e dane s� na 100% takie, jak je zapisano 3 lata temu? Czy
przywo�ana wcze�niej hurtownia danych co� tutaj pomo�e? W�tpi�, ale
ch�tnie naucz� si� czego� nowego!
> najpierw sam siďż˝ nastawiasz na zmiany starych danych, potem stwierdzasz,
> �e masz z tym problem. To prawdziwy "pomiar" jaki zna in�ynieria. czy
> raczej badania marketingowe kt�re wiadomo jak maj� wyj��?
To prawdziwy pomiar, w�a�ciwie seria pomiar�w i opracowanie wynik�w.
Stare dane sďż˝: niezmienne (wynik opracowania danych), oraz
/sporadycznie/ zmienne (dane z tabeli master). Dodatkowo do detali
dochodz� nowe opracowania, kt�re po zatwierdzeniu staj� si� niezmienne.
Ale to nadal IMHO nie wp�ywa to na metod� zapewnienia poprawno�ci danych.
> Mam swoj� dewiz�, �e system informatyczny wychodzi lepiej, jak
> odwzorowuje prawdďż˝, niďż˝ jak jego celem jest fikcja (w finansach,
> produkcji itd). Jak kto�, kto powiedzia�, �e "ma s�aba pami�� i dlatego
> woli m�wic prawd�"
Zgadzam si�. W tym temacie jest tak jak powiedzia� "cz�owiek z bran�y":
Z tymi danymi to jest tak jak z badaniami krwi - jak ktoďż˝ siďż˝ pomyli, to
po transfuzji pacjent robi si� zielony i ma 2 minuty, �eby po�egna� si�
z rodzin�. Jak jest cie� w�tpliwo�ci, to robimy pomiary od nowa,
niestety musimy czeka� (p�acimy ludziom a oni nie pracuj�) a koszt
(wykonania badania) jest du�y, wi�c potrzeba nam system, kt�ry zapewni
nam, �e dane s� ok!
--
Jerzy B.
Maciej Pilichowski
<jerzybrzuh.p...@gmail.com> wrote:
>1. określenie czy dane zapisane do tabeli są na pewno tymi samymi
>danymi, które z tabeli odczytujemy.
Na lokalnym komputerze tworzysz lokalna baze danych z hashami
rekordow, ktore zapisujesz do bazy zewnetrznej.
Oczywiscie pojawia sie pytanie, czy dane zapisane do bazy lokalnej sa
tymi samymi danymi...
>2. określenie, czy rekord odczytany z tabeli detail, na pewno jest
>poprawnie powiązany z właściwym rekordem z master.
>Problem dotyczy tylko wybranych pól w tabelach. Nie muszę /wręcz nie
>chcę/ robić tego sprawdzenia na całym rekordzie z tabeli.
Foreign key.
milego dnia, hej
--
Moja wyprzedaz wszystkiego: ksiazki, plyty, filmy.
http://www.garaz.pol.pl/
NKAB -
> W dniu 2011-09-07 22:08, Piotr M Kuďż˝ pisze:
> > Reasumuj�c chcesz pozwoli� na wstawianie i ogl�danie danych,
> > ale zabroniďż˝ modyfikowania.
>
> To nie tak. Mo�na wyci�gn�� taki wniosek, ale nie jest to za�o�enie.
> Uproszczony model tak wygl�da, ale opracowanie wynik�w jest kilku
> etapowe. Ju� na etapie wynik�w po�rednich musz� zapewni� deklarowan�
> poprawno�� danych, wi�c widzisz, �e nie t�dy droga. Oczywi�cie finalny
> wynik mo�na potraktowa� jako niezmienny, ale tak jak pisa�em powy�ej,
> jest to wniosek a nie za�o�enie.
>
No to pytanie, czy te serie zmieszczďż˝ siďż˝ na DVD-R?
Andrzej.
> > Mo�esz to osi�gn�� poprzez separacj�
> > u�ytkownik�w bazodanowych od tego kt�ry jest w�ascicielem
> > tabel z danymi,
>
> To nie jest rozwi�zanie podanego problemu. Uszkodzenie/przek�amanie
> (jakiekolwiek, nie wnikajmy jakie) danych nie zostanie tutaj wykryte.
>
> > steruj�c uprawnieniami. Poni�ej masz przyk�ad,
>
> Dzi�kuj� za przyk�ad, ale tutaj nie znajdzie zastosowania.
>
--
Wys�ano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
Jacek Czerwinski
>> W dniu 2011-09-07 19:08, Jerzy pisze:
>> Dlaczego mówisz, że nie jest to projekt typu "archiwalnego". Pomiar się
>> stał, dnia tego a tego, być może wymagał jakiś etapów pośrednich
>
> Ale co to zmienia? Co to wnosi do meritum? Ok, uznajmy, że wykonany i
> opracowany pomiar jest archiwalny. Co nam to daje w kontekście
> zapewnienia, że dane są na 100% takie, jak je zapisano 3 lata temu?
Że tak sobie "zagrantuj" tabelę, żeby był tylko insert (nawet dla
wyższego admina).
Jerzy
> <jerzybrzuh.p...@gmail.com> wrote:
>
>> >1. określenie czy dane zapisane do tabeli są na pewno tymi samymi
>> >danymi, które z tabeli odczytujemy.
> Na lokalnym komputerze tworzysz lokalna baze danych z hashami
> rekordow, ktore zapisujesz do bazy zewnetrznej.
>
> Oczywiscie pojawia sie pytanie, czy dane zapisane do bazy lokalnej sa
> tymi samymi danymi...
że mamy dwie lokalizacje danych/hashy. To jednak nie jest dobre
rozwiązanie w przypadku modelu c/s.
>> >2. określenie, czy rekord odczytany z tabeli detail, na pewno jest
>> >poprawnie powiązany z właściwym rekordem z master.
>> >Problem dotyczy tylko wybranych pól w tabelach. Nie muszę /wręcz nie
>> >chcę/ robić tego sprawdzenia na całym rekordzie z tabeli.
> Foreign key.
zweryfikować, że na 100% ten FK się nie przekłamał!
--
Pozdrawiam
Jerzy B.
Jerzy
> Jerzy<jerzybrzuh.p...@gmail.com> napisał(a):
>> > W dniu 2011-09-07 22:08, Piotr M Kuć pisze:
>>> > > Reasumując chcesz pozwolić na wstawianie i oglądanie danych,
>>> > > ale zabronić modyfikowania.
>> >
>> > To nie tak. Można wyciągnąć taki wniosek, ale nie jest to założenie.
>> > Uproszczony model tak wygląda, ale opracowanie wyników jest kilku
>> > etapowe. Już na etapie wyników pośrednich muszę zapewnić deklarowaną
>> > poprawność danych, więc widzisz, że nie tędy droga. Oczywiście finalny
>> > jest to wniosek a nie założenie.
>> >
> No to pytanie, czy te serie zmieszczą się na DVD-R?
Zmieszczą się. Jest to jakiś pomysł, aby napisać aplikację, która użyje
danych z płyty do weryfikacji danych bazie. Procedura będzie trochę
upierdliwa, ale akceptowalna ze względu na wymogi. Zaproponowana w innym
poście baza lokalna z hashami ma bardziej ulotny charakter od płyty DVD
trzymanej w sejfie. Wezmę to pod uwagę.
--
Pozdrawiam
Jerzy B.
Jerzy
> W dniu 2011-09-07 23:50, Jerzy pisze:
>> W dniu 2011-09-07 22:06, Jacek Czerwinski pisze:
>>> W dniu 2011-09-07 19:08, Jerzy pisze:
>>> Dlaczego m�wisz, �e nie jest to projekt typu "archiwalnego". Pomiar si�
>>> sta�, dnia tego a tego, by� mo�e wymaga� jaki� etap�w po�rednich
>>
>> Ale co to zmienia? Co to wnosi do meritum? Ok, uznajmy, �e wykonany i
>> opracowany pomiar jest archiwalny. Co nam to daje w kontek�cie
>
> �e tak sobie "zagrantuj" tabel�, �eby by� tylko insert (nawet dla
> wy�szego admina).
Piszesz w k�ko to samo. Je�eli chcesz pom�c, to prosz� przeczytaj ze
zrozumieniem opis problemu. Co z tego, �e pozwol� na tylko insert?
Za��my, �e dane zosta�y uszkodzone (np. zawiesi� si� OS na serwerze) i
jedna warto�� w ca�ej bazie zosta�a zmieniona. Nie mo�na wykluczy� na
100% takiej sytuacji.
Inny przypadek - uszkodzi�y si� pliki bazy. Robimy napraw�, walidacj� i
okazuje si�, �e 80% rekord�w jest ok. Gra warta �wieczki, bo te 80% to
kupa kasy. Musimy jednak wykaza�, �e po tej naprawie s� to na 100% te
dane, kt�re zosta�y zapisane. Co do jednego bitu. Kto si� pod tym
podpisze je�eli dane s� zabezpieczone tylko i wy��cznie kluczem obcym?
--
Pozdrawiam
JB.
Jerzy
dziękuję wszystkim za odpowiedzi. Niestety problem jest chyba za trudny
do dyskusji, bo /pomimo chęci/ nie udało się wypracować nic więcej, niż
to co sam zaproponowałem na początku. Jeszcze raz dziękuję wszystkim za
udział w dyskusji.
--
Pozdrawiam
Jerzy B.
Piotr M Kuć
> W dniu 2011-09-07 22:08, Piotr M Kuć pisze:
>> Reasumując chcesz pozwolić na wstawianie i oglądanie danych,
>> ale zabronić modyfikowania.
>
> To nie tak. Można wyciągnąć taki wniosek, ale nie jest to założenie.
> Uproszczony model tak wygląda, ale opracowanie wyników jest kilku
> etapowe. Już na etapie wyników pośrednich muszę zapewnić deklarowaną
> poprawność danych, więc widzisz, że nie tędy droga. Oczywiście finalny
> wynik można potraktować jako niezmienny, ale tak jak pisałem powyżej,
> jest to wniosek a nie założenie.
>
>> Możesz to osiągnąć poprzez separację
>> użytkowników bazodanowych od tego który jest włascicielem
>> tabel z danymi,
>
> To nie jest rozwiązanie podanego problemu. Uszkodzenie/przekłamanie
> (jakiekolwiek, nie wnikajmy jakie) danych nie zostanie tutaj wykryte.
DANE dołożyć dodatkowe tabele historyczne i oprogramować na triggerach
wypełnianie ich danymi sprzed modyfikacji. Natomiast użytkownikowi
WIDOK nie przyznajesz uprawnień dostępu do tych tabel histrycznych.
W ten sposób zawsze możesz odtworzyć dane pierwotne sprzed opracowywania.
Jerzy
modyfikacji? Twoje rozwiązanie w żadne sposób nie realizuje założeń.
Chyba, że każde dane trafiają od razu do dwóch tabel, czyli każdy zapis
danych (w szczególności pierwszy) jest od razu dublowany. Taką wersję
też rozważam, ale... nie wydaje się ona być lepsza od hashy. Co jeśli
dane mam różne? Wtedy para danych leci do kosza, bo nie wiem, które są
poprawne (bieżące, czy historyczne). To samo daje mi hash.
--
JB
geos
> 1. określenie czy dane zapisane do tabeli są na pewno tymi samymi
> danymi, które z tabeli odczytujemy.
do jednostki alokacji danych na dysku: obliczają ją przed zapisem bloku
danych, zapisują, odczytują co zapisały i obliczają sumę ponownie. jest
to mechanizm dedykowany do wykrywania przekłamań zapisu.
> 2. określenie, czy rekord odczytany z tabeli detail, na pewno jest
> poprawnie powiązany z właściwym rekordem z master.
wartościach decydują klucze obce i więzy. o poprawnym powiązaniach
logicznych decyduje aplikacja. jeśli ktoś nieuprawniony zmienia dane
zgodnie z regułami i więzami, to nie wykryjesz tego bez wzorcowego
źródła danych danych, o którym jesteś przekonany, że jest poprawne.
> Utrata danych nie jest problemem. Jeżeli widzę korupcję danych, to je usuwam bo jeżeli dane zginą to nic wielkiego się nie stanie. Istotne jest to, że jeżeli mam dane, to muszę mieć 100% pewność, że są poprawne.
przed błędami cpu, systemu operacyjnego, nieuprawnionymi modyfikacjami
sum kontrolnych, błędami przesyłu siecią itp?
audyt, uprawnienia, więzy, informacja kontrolna, backup, utrzymywanie
restrykcyjnego systemu wzorcowego to środki wystarczające większości.
podobnie jak ufasz hardwareowi i systemowi operacyjnemu zaufaj bazie w
kwestii spójności i poprawności. wykorzystaj ww. mechanizmy nadawania
uprawnień, opracuj więzy i zainwestuj w zewnętrzny restrykcyjny system
referencyjny.
geos
Jerzy
>> 1. określenie czy dane zapisane do tabeli są na pewno tymi samymi
>> danymi, które z tabeli odczytujemy.
>
> niektóre silniki rdbms posiłkują się dodatkową sumą kontrolną obliczaną
> do jednostki alokacji danych na dysku: obliczają ją przed zapisem bloku
> danych, zapisują, odczytują co zapisały i obliczają sumę ponownie. jest
> to mechanizm dedykowany do wykrywania przekłamań zapisu.
takich rozwiązań. Czy masz wiedzę i chcesz się nią podzielić, które
silniki wspierają takie rzeczy?
--
Jerzy B.
geos
checksum. dla checksum jesli baza jest mirrorowana to możliwe jest
automatyczne naprawienie strony (zostaje to odnotowane w odpowiednim
widoku systemowym). jeśli wystąpi rozbieżność to: blad 824 jest
zgłaszany, następuje logowanie do systemowego dziennika zdarzeń,
logowanie do dziennika błędów sql servera, w bazie msdb w tabeli
suspect_pages wpisywany jest id strony. administrator może kontrolować
"ręcznie" stan stron.
w sql server masz też mechanizmy audytu c2 oraz europejski standard
common criteria compliance do poziomu EAL4+.
w oracle: parametr DB_BLOCK_CHECKSUM sterujący zachowaniem procesu DBWx.
http://download.oracle.com/docs/cd/B28359_01/server.111/b28320/initparams046.htm
Maciej Pilichowski
<jerzybrzuh.p...@gmail.com> wrote:
>FK leży u podstaw, natomiast założenia są szersze - ja muszę
>zweryfikować, że na 100% ten FK się nie przekłamał!
Na 100% sie nie przeklamal.
Nie obraz sie, ale mam wrazenie, ze Ty nie rozwiazujesz problemu
technicznego, tylko szukasz magii na uleczenie paranoi. Paranoja nie
jest zla, o ile ma silne podstawy merytoryczne -- w tym przypadku
jednak tak wg mnie nie jest.
NKAB -
> Zmieszcz� si�. Jest to jaki� pomys�, aby napisa� aplikacj�, kt�ra u�yje
> danych z p�yty do weryfikacji danych bazie. Procedura b�dzie troch�
> upierdliwa, ale akceptowalna ze wzgl�du na wymogi. Zaproponowana w innym
> po�cie baza lokalna z hashami ma bardziej ulotny charakter od p�yty DVD
> trzymanej w sejfie. Wezmďż˝ to pod uwagďż˝.
Nie wiem z jakiej bazy korzystasz i w czym masz pisanďż˝ aplikacjďż˝
ale jak chcesz tylko por�wna� dane na dysku z danymi na DVD
to poprostu por�wnujesz zawarto�� rekord�w (rekord z rekordem, pole z polem)
a dla r�nic albo robisz pole w bazie na dysku albo wr�cz robisz now�
tabelk�, w kt�rej s� wykazane r�nice mi�dzy bazami.
Ja zrozumia�em pytanie tak, �e robisz tabel� wynik�w, kt�r�
chcia�by� zabezpieczy� przed jakimikolwiek zmianami aby
po jakim� czasie por�wna� dane stare (zabezpieczone) z nowymi danymi.
My�la�em, �e chodzi ci o gwarancj� bezpiecze�stwa danych.
Andrzej.
bo...@nano.pl
>
> Problem jest na razie ogólny, nie dotyczy żądnego konkretnego systemu
> DB. No, chyba że jakiś SZBD ma wbudowane mechanizmy do wspierania takich
> wymagań.
>
> Gdyby ktoś miał jakiś pomysł, albo doświadczenie w takim temacie, to
> zapraszam do dyskusji. Może istnieją jakieś wzorce opisujące takie
> przypadki?
>
Co do uszkodzenia. Najlepiej replikować bazę, masz wtedy drugą kopię,
która nie uległa uszkodzeniu. Możesz na jej podstawie weryfikować
poprawność rekordów. Jeśli to tak ważne dane można robić jeszcze jedno,
zapisywać każdy insert, każde update, nawet jako polecenie SQL do logu
tekstowego. Wtedy masz historię zmian i możesz po niej robić weryfikację.
--
wer <",,)~~
http://szumofob.eu
NKAB -
> On 06.09.2011 23:54, Jerzy wrote:
> >
> > DB. No, chyba Ĺźe jakiĹ SZBD ma wbudowane mechanizmy do wspierania takich
> > wymagaĹ .
> >
> > Gdyby ktoĹ miaĹ jakiĹ pomysĹ , albo doĹ wiadczenie w takim temacie, to
> > zapraszam do dyskusji. MoĹźe istniejÄ jakieĹ wzorce opisujÄ ce takie
> > przypadki?
> >
>
> Co do uszkodzenia. Najlepiej replikowaÄ bazÄ , masz wtedy drugÄ kopiÄ ,
> ktĂłra nie ulegĹ a uszkodzeniu. MoĹźesz na jej podstawie weryfikowaÄ
> poprawnoĹ Ä rekordĂłw. JeĹ li to tak waĹźne dane moĹźna robiÄ jeszcze jedno,
> zapisywaÄ kaĹźdy insert, kaĹźde update, nawet jako polecenie SQL do logu
------------------------------------------------------------------------
> tekstowego. Wtedy masz historiÄ zmian i moĹźesz po niej robiÄ weryfikacjÄ .
------------
Właśnie ja tak mam w systemie ewidencji ludności (meldunkowy)
gdzie zmiany są bardzo dynamiczne i wystarczy, że raz na miesiąc
porównuję dane .txt z bazą.
Inserty do .txt są robione na serwerze i na lokalach, są kontrolowane
za pomocą prostej aplikacji.
A ten pomysł wymusiły kiedyś na mnie ciągłe awarie zasilania podczas
remontu budynku gdzie upsy czasami nie zadziałaly.
Brak rekordu widać od razu w komunikacie na komputerze operatora,
który natychmiast kontaktuje się ze mną.
Andrzej.
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
William Bonawentura
> dziękuję wszystkim za odpowiedzi. Niestety problem jest chyba za trudny do
> dyskusji, bo /pomimo chęci/ nie udało się wypracować nic więcej, niż to co
> sam zaproponowałem na początku. Jeszcze raz dziękuję wszystkim za
IMHO to czego potrzebujesz to podpis elektroniczny. W zasadzie każda baza
posiada funkcje haszujące którymi wyliczysz "odcisk palca" interesujących
cię danych. Wyliczoną sumę kontrolną zapisujesz w dowolny sposób (choćby i
na karce) i za 10 lat uruchamiasz to samo zapytanie generujące skrót i
wiesz, czy dane które ono obejmuje zmieniły się czy też nie.