Czujesz się przytłoczony ilością czasu, jaką zajmie Ci nauka zawodu projektanta baz danych? Przeczytaj o podstawowych umiejętnościach i talentach, których będziesz potrzebować – to nie jest takie straszne!
Kiedy idziesz alejkami w supermarkecie, z wózkiem w jednej ręce i listą zakupów w drugiej, o czym myślisz? Jeśli jesteś podobny do mnie, wyobrażasz sobie, jak ulepszyć organizację półek, aby cotygodniowe zakupy były mniej czasochłonne. A może odczuwasz tę samą chęć do porządkowania i porządkowania informacji, gdy znajomy pokazuje Ci swoją dużą kolekcję czasopism. A może uderza, gdy zarządzasz swoimi listami odtwarzania, aby lepiej odpowiadały Twoim preferencjom. Jeśli przejdziesz przez życie, myśląc o tym, jak przedstawiać rzeczywistość w kategoriach bytów, atrybutów i relacji, to Twoim powołaniem jest bycie modelarzem baz danych.
Może nie jesteś aż tak ekstremalny, ale nadal pociąga Cię pomysł projektowania baz danych jako kariery. Tak czy inaczej, będziesz musiał opanować kilka nowych umiejętności. Niektóre z nich są czysto techniczne; możesz nauczyć się tych umiejętności, studiując lub czytając i pogłębiając je poprzez doświadczenie zawodowe. Inne umiejętności obejmują wiedzę nietechniczną, której możesz się nauczyć poprzez kursy, artykuły na blogu lub obserwując inne osoby.
Oto podsumowanie podstawowej wiedzy i umiejętności, które musi posiadać każdy projektant baz danych.
Potrzebują projektanci baz danych umiejętności twardych
Umiejętności twarde to te, które nabywa się poprzez naukę i doskonali poprzez praktykę. Jeśli potrafisz zademonstrować konkretnymi dowodami, że opanowałeś trudną umiejętność, oznacza to, że jesteś w stanie wykonać każde zadanie, które się z tym wiąże.
Jeśli chodzi o wiedzę o bazach danych, umiejętności twarde obejmują podstawy teorii baz danych i różne techniki stosowane do stosowania pojęć teoretycznych do rozwiązywania konkretnych problemów. Spójrzmy na każdą z twardych umiejętności potrzebnych projektantom baz danych.
Teoria bazy danych
Teoria baz danych jest pełna abstrakcyjnych pojęć, które mogą być trudne do zrozumienia, jeśli nie są powiązane z rzeczywistymi faktami. Model relacyjny, domeny, atrybuty, relacje i relacje, klucze podstawowe i obce, integralność encji, integralność referencyjna i ograniczenia domeny to tylko kilka przykładów. Jeśli dodasz jeszcze bardziej złożone sprawy (takie jak algebra relacyjna lub rachunek relacji), możesz się zastanawiać, czy nie byłoby lepiej wybrać karierę zajmującą się konkretnymi rzeczami, takimi jak ogrodnictwo lub gotowanie dla smakoszy.
Nie panikować. Gruntowna znajomość teorii baz danych jest ważna, jeśli planujesz prowadzić zajęcia w college'u lub wymyślić nowy sposób organizowania informacji. Jednak aby projektować bazy danych, wystarczy opanować pojęcia teoretyczne, które mają zastosowanie do rozwiązywania rzeczywistych problemów. Najważniejszym – ABC projektowania baz danych – jest model relacyjny.
Model relacyjny
Profesorowie uczelni powiedzą Ci, że model relacyjny to mechanizm organizacji danych oparty na teorii mnogości i logice predykatów. Ale to nie pomoże w codziennej pracy jako modelarz baz danych. W praktyce musisz wiedzieć, że model relacyjny jest intuicyjnym i prostym sposobem organizowania danych w postaci tabel – zwane relacjami – które składają się z wierszy (zwanych również krotkami). Każda tabela (lub relacja) jest zdefiniowana przez jej atrybuty (lub kolumny).
Podstawowe koncepcje modelu relacyjnego.
Wszystkie relacje powinny mieć jeden lub więcej wyróżniających się atrybutów, które reprezentują unikalny identyfikator dla każdej krotki. W slangu bazy danych jest to klucz tabeli. Atrybuty niekluczowe są zależne od klucza w tym sensie, że każda wartość klucza określa pojedynczą możliwą wartość dla każdego atrybutu.
Wyobraź sobie tabelę informacji o pojeździe, w której kluczem jest tablica rejestracyjna. Tablica rejestracyjna określa atrybuty każdego pojazdu (takie jak producent, model, właściciel itp.), ponieważ zasady domeny uniemożliwiają dwóm różnym pojazdom korzystanie z tej samej tablicy rejestracyjnej.
Relacyjne bazy danych
Systemy zarządzania relacyjnymi bazami danych (RDBMS) realizują model relacyjny, respektując jego zasady. Oferują sposoby pobierania informacji za pomocą zapytań i aktualizowania informacji za pomocą transakcji. Aby informacje w relacyjnej bazie danych odzwierciedlały rzeczywiste fakty i sytuacje, można zdefiniować warunki lub ograniczenia specyficzne dla domeny, której dotyczy baza danych. Na przykład w tabeli przechowującej informacje o uczniach można nałożyć ograniczenie, aby daty urodzenia nie zezwalały na przyszłe lub zbyt odległe daty.
Organizacja tabel w bazie danych jest powszechnie nazywana schematem bazy danych. Oprócz tabel schemat zawiera szczegółowe ograniczenia dotyczące par tabel nazywanych relacjami. Relacja łączy dwie tabele, nakładając ograniczenie, że wartości w polu jednej z tabel odpowiadają wartościom w kluczu podstawowym drugiej tabeli.
Schematy baz danych są zwykle reprezentowane przez diagram relacji encji (ERD), wspólne narzędzie dla każdego projektanta baz danych.
ERD reprezentujący model danych klienta.
Anomalie i normalizacja
Wszystkie koncepcje, które omówiliśmy do tej pory, są dość jasne, prawda? Teraz możemy porozmawiać o anomaliach, które występują w bazach danych z powodu wadliwego lub nieodpowiedniego projektu (tj. baza danych nie odzwierciedla odpowiednio rzeczywistości, którą próbuje przedstawić).
Anomalie występują, gdy operacja wstawiania, aktualizowania lub usuwania generuje niespójności w danych. Załóżmy na przykład, że masz tabelę do przechowywania danych sprzedaży. Dla każdej sprzedaży (tj. w każdym rekordzie tabeli) zapisywane są nazwisko i adres klientów. Anomalia wygląda następująco:
- Jeśli adres klienta zostanie zmodyfikowany w jednej ze sprzedaży i
- Ten sam klient ma inną sprzedaż,
- Inna sprzedaż będzie miała nieaktualny adres.
Aby uniknąć anomalii, można zastosować technikę projektowania zwaną normalizacją bazy danych. Obejmuje to dekompozycję tabel i kolumn (tj. dzielenie ich na mniejsze części), aby uniknąć wad projektowych, takich jak:
- Kolumny zawierające więcej niż jedną informację (np. numer identyfikacyjny przedmiotu oraz jego nazwę).
- Przechowywanie tych samych informacji więcej niż raz w tej samej tabeli.
- Pola zależne od innych pól niekluczowych.
Tabela nieznormalizowana (po lewej) a schemat znormalizowany (po prawej).
Hurtowni danych i denormalizacja
Niektóre bazy danych są używane do wysyłania zapytań do dużych ilości informacji zamiast przetwarzania transakcji online (OLTP). Te bazy danych nazywane są hurtowniami danych.
Informacje w hurtowni danych nie pochodzą z interfejsów użytkownika (np. wprowadzane bezpośrednio z systemu zamówień e-commerce). Pochodzi z procesów wsadowych, które zbierają informacje z różnych źródeł, przetwarzają je, czyszczą i przechowują w tabelach. Z tego powodu możemy założyć, że hurtownie danych nie są narażone na te same anomalie, co konwencjonalne bazy danych.
Z tego powodu hurtownie danych nie muszą utrzymywać tych samych warunków normalizacji, co baza danych OLTP. Z drugiej strony ważniejsza jest optymalizacja wydajności zapytań w hurtowniach danych. Dlatego w hurtowni danych stosowana jest denormalizacja; ta technika wykorzystuje pewną nadmiarowość w celu uproszczenia zapytań i uniknięcia zaśmiecania schematów nadmierną liczbą tabel.
Typowy schemat hurtowni danych.
Wielkie dane
Podobnie jak hurtownie danych, koncepcja Big Data odnosi się do repozytoriów, które przechowują duże ilości danych. Istnieje jednak istotna różnica między tymi dwoma koncepcjami. Hurtownia danych jest zaprojektowana do określonego celu i ma na celu generowanie raportów, których zachowanie i format są znane z góry.
Z drugiej strony Big Data ma na celu zbieranie dużych ilości danych, które są generowane z dużą prędkością z różnych źródeł – m.in. informacje z mediów społecznościowych, mikrotransakcji czy inteligentnych czujników. Tę ogromną ilość informacji można wykorzystać do eksploracji i analizy lub do trenowania modeli uczenia maszynowego.
W projektowaniu baz danych Big Data priorytetem jest oszczędność przestrzeni dyskowej i partycjonowanie danych (między innymi), aby umożliwić równoległość i przechwytywanie danych w czasie rzeczywistym. Ponadto używane są nierelacyjne lub NoSQL systemy baz danych, które oferują lepsze alternatywy dla obsługi nieustrukturyzowanych informacji.
Technologie takie jak NoSQL i sama koncepcja Big Data są stosunkowo nowe w porównaniu z relacyjnymi bazami danych, które mają już ponad 40 lat. Dlatego jako projektant baz danych musisz zwracać uwagę na nowe osiągnięcia w tej dziedzinie. Pamiętaj, że Big Data to także wielki biznes. Wiele firm chce zająć w nim wiodącą pozycję i opracowuje w tym celu nowe narzędzia i technologie.
Administracja bazą danych
Gdy baza danych jest już uruchomiona, ktoś musi zająć się jej codziennym zarządzaniem. Oznacza to wykonywanie rutynowych zadań, tak aby baza danych nigdy nie stała się wąskim gardłem dla aplikacji, które z niej korzystają. Zadania administracyjne obejmują utrzymywanie kopii zapasowych, monitorowanie zużycia przestrzeni dyskowej, wykrywanie awarii między procesami i naprawianie problemów z danymi, które uniemożliwiają normalne działanie aplikacji.
Osobą, która ma umiejętności bazodanowe, aby zająć się tymi zadaniami, jest administrator bazy danych lub DBA – jeśli taki istnieje. W bardzo małych organizacjach – lub w środowiskach programistycznych, w których działanie baz danych nie jest krytyczne dla biznesu – odpowiedzialność za utrzymanie bazy danych może spaść na projektanta baz danych. Dlatego powinieneś mieć pewną wiedzę, która pozwoli Ci przejąć DBA w określonych sytuacjach. Jednak pod żadnym pozorem nie należy przyjmować odpowiedzialności za administrowanie bazą danych w środowisku produkcyjnym obsługującym aplikacje biznesowe lub o znaczeniu krytycznym .
Zadania administracyjne różnią się znacznie w zależności od systemu bazy danych i infrastruktury, na której jest on zamontowany. Na przykład zadania związane z zarządzaniem bazami danych Microsoft SQL Server bardzo różnią się od zadań związanych z zarządzaniem bazami danych MySQL czy Oracle. A zarządzanie serwerem działającym lokalnie na swoim notebooku bardzo różni się od zarządzania serwerem działającym w chmurze.
Nie polecam poświęcania dużo wysiłku na naukę zarządzania konkretnym serwerem bazodanowym, ponieważ przez całą swoją karierę będziesz miał do czynienia z bardzo różnymi bazami danych i środowiskami. Specjalizacja tylko w jednym nie pomoże.
Zarządzanie współbieżnością i transakcjami
Równoczesny dostęp do bazy danych może powodować problemy w aplikacjach, gdy kilku użytkowników próbuje jednocześnie uzyskać dostęp do tego samego zasobu. Możemy pomyśleć, że jako projektanci to nie jest nasza sprawa i że to DBA jest odpowiedzialny za radzenie sobie z tymi problemami. Możemy również pomyśleć, że to wina programistów za tworzenie aplikacji, które na to pozwalają.
Jednak projektanci mogą zrobić swoją część, aby zminimalizować potencjalne problemy ze współbieżnością, projektując schematy, które ich unikają.
Wiele problemów ze współbieżnością występuje, gdy długie i złożone transakcje są wykonywane na bazie danych; podczas przetwarzania transakcji dane tabele są blokowane dla innych procesów, które potrzebują ich do odczytu lub zapisu informacji. Aby uniknąć tego rodzaju problemów, najlepszą rzeczą, jaką możesz zrobić, jest upewnienie się, że Twoje projekty są zgodne co najmniej do trzeciej normalnej postaci. Wtedy obowiązkiem programisty będzie prawidłowe przemyślenie transakcji, aby uniknąć impasu.
Ale możesz również użyć strategii, które unikają współbieżności, takich jak partycjonowanie schematów lub grupowanie tabel zgodnie z funkcją, którą spełnia każda z nich.
Wyobraźmy sobie bazę danych dla witryny e-commerce. Tabele danych podstawowych dla produktów, zapasów i cen można umieścić w jednym schemacie, a zamówienia i sprzedaż w innym, wraz z widokami lub replikami tabel z pierwszego schematu tylko do odczytu. Pomaga to uniknąć błędów podczas wykonywania transakcji, które aktualizują dane podstawowe.
Narzędzia do projektowania baz danych
Jeśli rozumiesz model relacyjny, diagramy relacji encji i techniki normalizacji, możesz projektować bazy danych za pomocą tylko ołówka i papieru. Jednak wydajność zostanie znacznie zwiększona, jeśli użyjesz inteligentnego narzędzia, zwłaszcza takiego, które może zautomatyzować niektóre zadania projektowe, takie jak przenoszenie lub modyfikowanie obiektów na diagramie, wykrywanie błędów projektowych, generowanie skryptów SQL do tworzenia lub aktualizowania bazy danych i odwracanie inżynieria istniejącego projektu bazy danych.
Opanowanie specjalistycznego narzędzia jakim jest platforma Vertabelo pozwoli Ci pracować znacznie szybciej. I pozwoli Ci wyróżnić się spośród innych projektantów, którzy nie mają tej pomocy.
SQL i programowanie
Wszyscy chcielibyśmy móc dostarczyć projekt bazy danych, powiedzieć z dumą „Moja praca tutaj jest skończona” i wyjechać na zasłużone wakacje. Ale zazwyczaj taka idealna sytuacja nigdy się nie zdarza. Po zakończeniu projektowania programiści aplikacji będą musieli z niego skorzystać i będą musieli mieć Cię w pobliżu, aby im pomóc.
Jednym ze sposobów dalszego asystowania w projekcie programistycznym jest pisanie widoków, wyzwalaczy, procedur składowanych i innych rzeczy w języku SQL (Structured Query Language) w celu rozwiązania określonych potrzeb aplikacji. Innym sposobem jest nadzorowanie zadań programistycznych, które są wykonywane za pomocą czegoś, co nazywa się mapowaniem obiektowo-relacyjnym (ORM).
ORM mają na celu abstrakcję dostępu do danych z określonego RDBMS. Dobrą stroną tego jest to, że programiści nie muszą martwić się o specyfikę bazy danych, z której będą korzystać – innymi słowy, nie muszą się martwić, czy RDBMS to MySQL, Oracle, IBM DB2, MS SQL Server lub coś innego.
Wadą ORM jest to, że obiekty projektu bazy danych — tabele, atrybuty i relacje — są zdefiniowane w kodzie języka programowania wysokiego poziomu, takiego jak Java, Python, R lub C#. Innymi słowy, są tam, gdzie my, projektanci baz danych, nie możemy ich zobaczyć.
Rozwiązaniem tego problemu są metodyki rozwoju Agile i ich filozofia współpracy. Promują one projektantów i programistów współpracujących ze sobą w trakcie projektu, więc warto utrzymywać dobre relacje z programistami. Powinieneś chcieć usiąść obok nich, spojrzeć na kod programowania i wspólnie pisać definicje obiektów danych.
Projektanci baz danych umiejętności miękkich powinni mieć
Poza wiedzą teoretyczną i techniczną charakterystyczną dla projektowania baz danych projektant powinien w idealnym przypadku posiadać inne umiejętności zwane „umiejętnościami miękkimi”. Te umiejętności – jak bycie dobrym komunikatorem i zrozumienie wizji biznesowej produktu końcowego – pośrednio wpływają na sukces Twojej pracy. Te, które wymienię poniżej, to tylko kilka przykładów, ale istnieje wiele innych umiejętności miękkich, które są bardzo cenione przez potencjalnych pracodawców.
Wizja biznesowa
Projektując bazę danych, reprezentujesz rzeczywistość biznesową w kategoriach powiązanych ze sobą obiektów danych. Widzieliśmy, że projekt musi spełniać warunki standaryzacji i musi unikać niespójności, anomalii i problemów ze współbieżnością. Ale równie ważne – a może nawet ważniejsze – jest to, aby projekt był zgodny z wizją biznesową osoby, która płaci ci pensję.
Zrozumienie wizji biznesowej pozwoli lepiej zrozumieć znaczenie każdego wymagania i pokierować decyzjami, tak aby projekty były lepiej dopasowane do celów organizacji.
Oto prosty przykład tego, jak zrozumienie wizji biznesowej ukształtuje Twoją pracę. Możesz pomyśleć, że użycie klucza zastępczego w tabeli zaśmieca Twój projekt, dodając niepotrzebny i denerwujący element. Jednak pominięcie klucza zastępczego może spowolnić zapytania w tej tabeli, ponieważ klucz typu INTEGER może zapewnić lepszą wydajność. Jeśli wizją firmy jest dostarczanie szybkich zapytań, kluczem zastępczym jest droga.
Umiejętności komunikacyjne
Nie wystarczy tworzyć świetne projekty. Musisz także umieć wyjaśnić, dlaczego Twój projekt działa. Sposobem na to jest wiedza, jak to przedstawić, zarówno dyskursywnie (w mowie lub piśmie), jak i wizualnie.
Zrób listę mocnych stron swojego projektu, aby się wyróżniały. Pomyśl o decyzjach, które podjąłeś, aby go stworzyć i zapisz powody tych decyzji. Przygotuj się do obrony swoich decyzji i projektu przed tymi, którzy go nie rozumieją lub chcą go zmienić, czyniąc go niedoskonałym lub wadliwym.
Ale musisz też być gotów zaakceptować konstruktywną krytykę i rozważyć punkty widzenia, które różnią się od twojego. Czasami programista może zauważyć problem, którego nie zauważyłeś i udzielić ci dobrej rady. Nie zwalniaj swoich współpracowników, myśląc, że nie mają wiedzy o bazach danych.
Umiejętności interpersonalne
Skomentowałem powyżej zalety dobrych relacji z programistami. Bez względu na to, jak zaawansowany jesteś w swojej dziedzinie, ważne jest, abyś zachowywał przyjacielskie podejście do wszystkich członków zespołu, niezależnie od tego, czy jest to tester, który wykrył usterkę zmuszającą Cię do przemyślenia części projektu, czy kierownik projektu, który potrzebuje do wykonania zadania w określonym terminie. Krótko mówiąc, musisz być graczem zespołowym . Nikt nie chce mieć w swoim zespole primadonny, które czują się niezastąpione i chcą narzucać swoje zasady.
Może się zdarzyć, że nie jesteś jedynym projektantem baz danych w zespole programistycznym. Może musisz poprowadzić podgrupę swoich kolegów. Aby to zrobić, musisz wykazać się umiejętnościami przywódczymi i działać jako kierownik projektu, upewniając się, że zespół projektantów baz danych spełnia swoje cele i pozostaje zmotywowany.
Jak nauczyć się umiejętności projektowania baz danych
Umiejętności potrzebne do bycia projektantem baz danych możesz zdobyć dzięki stopniom uniwersyteckim, kursom, książkom i specjalistycznym artykułom. Zaletą kursów uniwersyteckich jest to, że dają ci całą potrzebną wiedzę i potwierdzają tę wiedzę z uznanym stopniem. Wadą jest to, że wymagają dużej inwestycji czasu i pieniędzy.
Jeśli wolisz uczyć się samodzielnie, czytając książki i artykuły, zaoszczędzisz czas i pieniądze – ale będziesz potrzebować przewodnika, który poprowadzi Cię przez najważniejsze tematy i oceni Twoją wiedzę. I będziesz musiał wykazać się swoją wiedzą w praktyczny sposób, ponieważ nie będziesz mieć dyplomu, aby to zrobić.
W każdym razie, niezależnie od tego, czy uczysz się na kursach, czy na lekturze, ta wiedza będzie służyć tylko jako podstawa. Najwięcej nauczysz się tworząc modele, stawiając czoła realnym problemom i obserwując działania swoich kolegów i współpracowników.
