Мислите за дизайн на база данни за регистриране на одит? Спомнете си какво се случи с Хензел и Гретел:те смятаха, че оставянето на обикновена следа от галета е добър начин да проследят стъпките им.
Когато проектираме модел на данни, ние сме обучени да прилагаме философията, че сега е всичко, което съществува . Например, ако проектираме схема за съхраняване на цени за продуктов каталог, може да мислим, че базата данни трябва само да ни каже цената на всеки продукт в настоящия момент. Но ако искахме да знаем дали цените са променени и ако е така, кога и как са настъпили тези промени, щяхме да имаме проблеми. Разбира се, бихме могли да проектираме базата данни специално, за да поддържаме хронологичен запис на промените – често известен като одитна пътека или одитен регистър.
Регистрирането на одит позволява на база данни да има „памет“ за минали събития. Продължавайки с примера с ценова листа, правилният дневник на одита ще позволи на базата данни да ни каже точно кога дадена цена е била актуализирана, каква е била цената преди да бъде актуализирана, кой я е актуализирал и откъде.
Решения за регистриране на одит на база данни
Би било чудесно, ако базата данни може да запази моментна снимка на състоянието си за всяка промяна, която се случва в нейните данни. По този начин можете да се върнете към всеки момент във времето и да видите как са били данните в този точен момент, все едно превъртате филм назад. Но този начин за генериране на регистриране на одит е очевидно невъзможен; полученият обем информация и времето, необходимо за генериране на регистрационните файлове, биха били твърде големи.
Стратегиите за регистриране на одит се основават на генериране на одитни пътеки само за данни, които могат да бъдат изтрити или модифицирани. Всяка промяна в тях трябва да бъде одитирана, за да се отменят промените, да се направят заявки за данните в таблици с история или да се проследи подозрителна дейност.
Има няколко популярни техники за регистриране на одит, но нито една от тях не служи на всички цели. Най-ефективните често са скъпи, ресурсоемки или влошаващи производителността. Други са по-евтини по отношение на ресурсите, но са или непълни, тромави за поддръжка или изискват жертва на качеството на дизайна. Коя стратегия ще изберете ще зависи от изискванията на приложението и ограниченията на производителността, ресурсите и принципите на проектиране, които трябва да спазвате.
Изходни решения за регистриране
Тези решения за регистриране на одит работят чрез прихващане на всички команди, изпратени до базата данни и генериране на регистър на промените в отделно хранилище. Такива програми предлагат множество опции за конфигуриране и отчитане за проследяване на действията на потребителите. Те могат да регистрират всички действия и заявки, изпратени в база данни, дори когато идват от потребители с най-високи привилегии. Тези инструменти са оптимизирани за минимизиране на въздействието върху производителността, но това често идва с парична цена.
Цената на специалните решения за одитни пътеки може да бъде оправдана, ако работите с изключително чувствителна информация (като медицински досиета), където всяка промяна на данните трябва да бъде перфектно наблюдавана и подлежаща на одит, а одитната пътека трябва да бъде непроменена. Но когато изискванията за одитната пътека не са толкова строги, цената на специално решение за регистриране може да бъде прекомерна.
Вградените инструменти за мониторинг, предлагани от системите за релационни бази данни (RDBMS), също могат да се използват за генериране на одитни пътеки. Опциите за персонализиране позволяват филтриране кои събития се записват, за да не се генерира ненужна информация или да не се претоварва базата данни с операции за регистриране, които няма да бъдат използвани по-късно. Така генерираните логове позволяват подробно проследяване на операциите, изпълнявани върху таблиците. Те обаче не са полезни за запитване на таблици с история, тъй като записват само събития.
Най-икономичният вариант за поддържане на одитна пътека е специално да проектирате вашата база данни за регистриране на одит. Тази техника се основава на регистрационни таблици, които се попълват от тригери или механизми, специфични за приложението, което актуализира базата данни. Няма универсално приет подход за проектиране на база данни за регистриране на одит, но има няколко често използвани стратегии, всяка от които има своите плюсове и минуси.
Техники за проектиране на регистриране на одит на база данни
Версиониране на реда за влизане в одит
Един от начините за поддържане на одитна пътека за таблица е да добавите поле, което указва номера на версията на всеки запис. Вмъкванията в таблицата се записват с първоначален номер на версията. Всякакви модификации или изтривания всъщност стават операции за вмъкване, при които се генерират нови записи с актуализираните данни и номерът на версията се увеличава с единица. Можете да видите пример за това регистриране на одит на място по-долу:
Забележка:Дизайните на таблици с вградени версии на редове не могат да бъдат свързани чрез връзки с външни ключове.
В допълнение към номера на версията, някои допълнителни полета трябва да бъдат добавени към таблицата, за да се определи произходът и причината за всяка промяна, направена в запис:
- Дата/часът, когато е записана промяната.
- Потребителят и приложението.
- Извършеното действие (вмъкване, актуализиране, изтриване) и т.н. За да бъде ефективна одитната пътека, таблицата трябва да поддържа само вмъквания (актуализации и изтривания не трябва да се разрешават). Таблицата също така задължително изисква сурогатен първичен ключ, тъй като всяка друга комбинация от полета ще подлежи на повторение.
За да получите достъп до актуализираните данни от таблицата чрез заявки, трябва да създадете изглед, който връща само най-новата версия на всеки запис. След това трябва да замените името на таблицата с името на изгледа във всички заявки, с изключение на тези, които са специално предназначени за преглед на хронологията на записите.
Предимството на тази опция за версия е, че не изисква използване на допълнителни таблици за генериране на одитната пътека. Освен това към одитираните таблици се добавят само няколко полета. Но има огромен недостатък:ще ви принуди да правите някои от най-често срещаните грешки в дизайна на базата данни. Те включват неизползване на референтна цялост или естествени първични ключове, когато е необходимо да се направи това, което прави невъзможно прилагането на основните принципи на дизайна на диаграмата обект-връзка. Можете да посетите тези полезни ресурси за грешки в дизайна на база данни, така че ще бъдете предупредени какви други практики трябва да избягвате.
Таблици в сянка
Друга опция за одитната пътека е да генерирате таблица с сянка за всяка таблица, която трябва да бъде одитирана. Таблиците в сянка съдържат същите полета като таблиците, които те одитират, плюс специфичните полета за одит (същите, споменати за техниката за версия на реда).
Таблиците в сянка копират същите полета като таблиците, които одитират, плюс полетата, специфични за целите на одита.
За генериране на одитни пътеки в сенчести таблици, най-сигурната опция е да създадете тригери за вмъкване, актуализиране и изтриване, които за всеки засегнат запис в оригиналната таблица генерират запис в таблицата за одит. Тригерите трябва да имат достъп до цялата информация за одит, която трябва да запишете в таблицата със сянка. Ще трябва да използвате специфичната функционалност на машината за база данни, за да получите данни като текущата дата и час, регистриран потребител, име на приложението и местоположението (мрежов адрес или име на компютър), където е възникнала операцията.
Ако използването на тригери не е опция, логиката за генериране на следите за одит трябва да бъде част от стека на приложението, в слой, идеално разположен точно преди слоя за постоянство на данни, така че да може да прихваща всички операции, насочени към базата данни.
Този вид регистрационна таблица трябва да позволява само вмъкване на запис; ако позволяват промяна или изтриване, одитната пътека вече няма да изпълнява своята функция. Таблиците също трябва да използват сурогатни първични ключове, тъй като зависимостите и връзките на оригиналните таблици не могат да бъдат приложени към тях.
Ако таблицата, за която сте създали одитна пътека, има таблици, от които зависи, те също трябва да имат съответни сенчести таблици. Това е така, че одитната пътека да не остане сира, ако се направят промени в другите таблици.
Таблиците в сянка са удобни поради тяхната простота и защото не влияят върху целостта на модела на данните; одитните пътеки остават в отделни таблици и са лесни за запитване. Недостатъкът е, че схемата не е гъвкава:всяка промяна в структурата на основната таблица трябва да бъде отразена в съответната таблица в сянка, което затруднява поддържането на модела. Освен това, ако регистрирането на одит трябва да се приложи към голям брой таблици, броят на сенчестите таблици също ще бъде висок, което ще направи поддръжката на схемата още по-трудна.
Общи таблици за регистриране на одит
Трета опция е да създадете общи таблици за регистрационни файлове за одит. Такива таблици позволяват регистрирането на всяка друга таблица в схемата. За тази техника са необходими само две таблици:
Заглавна таблица, която записва:
- Дата и час на промяната.
- Името на таблицата.
- Ключът на засегнатия ред.
- Потребителските данни.
- Типът на извършената операция.
Таблица с подробности, която записва:
- Имената на всяко засегнато поле.
- Стойностите на полето преди промяната.
- Стойността(ите) на полето след промяната. (Можете да пропуснете това, ако е необходимо, тъй като може да се получи чрез справка със следния запис в одитната пътека или съответния запис в одитираната таблица.)
Използването на общи таблици за одит на регистрационни файлове поставя ограничения върху типовете данни, които могат да бъдат одитирани.
Предимството на тази стратегия за регистриране на одит е, че не изисква никакви таблици, различни от двете, споменати по-горе. Освен това в него се съхраняват записи само за полетата, които са засегнати от операция. Това означава, че няма нужда да се копира цял ред от таблица, когато е променено само едно поле. В допълнение, тази техника ви позволява да водите дневник на толкова таблици, колкото искате – без да претрупвате схемата с голям брой допълнителни таблици.
Недостатъкът е, че полетата, които съхраняват стойностите, трябва да бъдат от един тип – и достатъчно широки, за да съхраняват дори най-големите полета на таблиците, за които искате да генерирате регистрационен файл за одит. Най-често се използват полета от тип VARCHAR, които приемат голям брой знаци.
Ако, например, трябва да генерирате регистрационен файл за одит за таблица, която има едно поле VARCHAR от 8000 знака, полето, което съхранява стойностите в таблицата за одит, трябва също да има 8000 знака. Това е вярно, дори ако просто съхранявате едно цяло число в това поле. От друга страна, ако вашата таблица има полета от сложни типове данни, като изображения, двоични данни, BLOB и т.н., ще трябва да сериализирате съдържанието им, така че да могат да се съхраняват в полетата VARCHAR на регистрационните таблици.
Изберете разумно дизайна на дневника си за одит на базата данни
Видяхме няколко алтернативи за генериране на регистриране на одит, но нито една от тях не е наистина оптимална. Трябва да приемете стратегия за регистриране, която не влияе съществено върху производителността на вашата база данни, не я кара да нараства прекомерно и може да отговори на вашите изисквания за проследимост. Ако искате да съхранявате регистрационни файлове само за няколко таблици, сенчестите таблици може да са най-удобната опция. Ако искате гъвкавостта да регистрирате всяка таблица, обикновените таблици за регистриране може да са най-добри.
Открили ли сте друг начин да поддържате дневник за одит за вашите бази данни? Споделете го в секцията за коментари по-долу – вашите колеги дизайнери на бази данни ще ви бъдат много благодарни!
