Zgodnie z zasadami ACID dotyczącymi wykonywania transakcji wymóg atomowości (ang. atomicity) oznacza, że
A. zmiany zatwierdzonej transakcji przetrwają nawet awarię systemu
B. po zakończeniu transakcji baza danych spełnia wszystkie więzy integralności
C. transakcje wykonywane równocześnie nie widzą zmian wprowadzanych przez siebie nawzajem
D. transakcja zostaje wykonana w całości albo nie zostaje wykonana wcale
Atomowość w ACID oznacza zasadę wszystko albo nic: transakcja ma zostać wykonana w całości, a jeśli choć jeden jej etap się nie powiedzie, system powinien wycofać wszystkie wcześniejsze zmiany wykonane w ramach tej samej transakcji. To bardzo ważne w bazach danych, bo chroni dane przed stanem pośrednim, czyli takim trochę „rozgrzebanym”. Przykład z życia: przelew bankowy składa się z odjęcia pieniędzy z jednego konta i dodania ich na drugie. Jeśli po odjęciu środków nastąpi awaria, atomowość wymaga cofnięcia operacji, zamiast zostawienia klienta bez pieniędzy i bez zaksięgowania przelewu. W praktyce realizuje się to przez mechanizmy BEGIN TRANSACTION, COMMIT i ROLLBACK, dzienniki transakcyjne oraz odpowiednie silniki baz danych, np. InnoDB w MySQL. Moim zdaniem to jedna z najważniejszych zasad przy projektowaniu aplikacji biznesowych, bo bez niej nawet poprawne zapytania SQL mogą prowadzić do bałaganu w danych. W dobrych praktykach branżowych transakcjami obejmuje się operacje, które logicznie muszą stanowić jedną całość, np. zamówienie, płatność, rezerwacja towaru albo aktualizacja kilku powiązanych tabel.
W tym pytaniu łatwo pomylić poszczególne litery skrótu ACID, bo wszystkie dotyczą poprawnego wykonywania transakcji, ale każda opisuje trochę inny aspekt. Stwierdzenie, że transakcje wykonywane równocześnie nie widzą zmian wprowadzanych przez siebie nawzajem, odnosi się do izolacji. Izolacja zabezpiecza przed problemami współbieżności, takimi jak brudne odczyty, niepowtarzalne odczyty czy fantomy. W praktyce ustawia się ją poziomami izolacji, np. READ COMMITTED albo SERIALIZABLE, ale to nie jest atomowość. Z kolei trwałość oznacza, że dane zatwierdzone przez COMMIT powinny przetrwać awarię systemu, restart serwera czy chwilowy problem z zasilaniem. Tu wchodzą w grę logi transakcyjne, zapis na dysk i mechanizmy odzyskiwania bazy danych. Mylenie trwałości z atomowością jest dość częste, bo obie zasady kojarzą się z bezpieczeństwem danych, ale działają w innym momencie cyklu życia transakcji. Informacja o tym, że po zakończeniu transakcji baza spełnia wszystkie więzy integralności, dotyczy spójności. Chodzi o zachowanie reguł, takich jak klucze główne, klucze obce, ograniczenia UNIQUE, CHECK czy poprawne relacje między tabelami. Atomowość nie mówi więc ani o widoczności zmian, ani o przetrwaniu awarii po zatwierdzeniu, ani bezpośrednio o więzach integralności. Ona pilnuje, żeby transakcja nie wykonała się tylko częściowo. Z mojego doświadczenia najlepiej zapamiętać to na przykładzie przelewu: albo oba kroki przelewu są wykonane, albo żaden. Inaczej baza może wyglądać poprawnie technicznie, ale dane biznesowo będą popsute.