Co to jest modelowanie danych?

Modelowanie danych jest procesem tworzenia diagramu (np. ERD) relacji pomiędzy różnymi typami informacji, które mają być przechowywane w bazie danych, który pomaga nam myśleć systematycznie o kluczowych punktach danych, które mają być przechowywane i wyszukiwane, oraz o tym, jak powinny być one pogrupowane i powiązane

Model danych opisuje informacje w systematyczny sposób, który pozwala na ich efektywne przechowywanie i wyszukiwanie w systemie relacyjnej bazy danych, który może być postrzegany jako sposób tłumaczenia logiki dokładnego opisywania rzeczy w świecie rzeczywistym i relacji pomiędzy nimi na reguły, które mogą być przestrzegane i egzekwowane przez kod komputerowy. Jednym z celów modelowania danych jest stworzenie najbardziej efektywnej metody przechowywania informacji, przy jednoczesnym zapewnieniu pełnego dostępu i raportowania.

Diagram relacji encji dla modelowania danych

Diagram relacji encji (ERD), początkowo zaproponowany przez Petera Chena w 1976 roku, jest wizualną reprezentacją modelowania danych przy użyciu symboli i notacji, która opisuje, jak te dane są ze sobą powiązane. Może on być bezpośrednio wykorzystywany przez programistów baz danych jako schemat implementacji danych w konkretnych aplikacjach. Każdy obiekt, taki jak encje, atrybuty encji, zestawy relacji i inne atrybuty relacji mogą być scharakteryzowane za pomocą diagramu ER.

An ERD pozwala czytelnikom zrozumieć relacje między różnymi polami w efektywny sposób. Symbole są wykorzystywane do efektywnego reprezentowania informacji, a także pomagają w zrozumieniu działania bazy danych. Diagramy ER stanowią bardzo użyteczną technikę modelowania danych, która obejmuje:

  1. Schematy ER są łatwe do zrozumienia i nie wymagają od osoby przechodzącej intensywne szkolenie, aby móc pracować z nimi wydajnie i dokładnie. Oznacza to, że projektanci mogą używać diagramów ER do łatwej komunikacji z programistami, klientami i użytkownikami końcowymi, niezależnie od ich biegłości informatycznej.
  2. Schematy ER są łatwo przekładalne na tabele relacyjne, które mogą być używane do szybkiego budowania baz danych.
  3. Schematy ERD mogą być stosowane w innych kontekstach, takich jak opisywanie różnych relacji i operacji w organizacji.

Elementy ERD

Modelowanie ERD jest odgórną strukturą projektowania bazy danych, która rozpoczyna się od identyfikacji ważnych danych zwanych encjami i relacjami w połączeniu z danymi, które muszą być scharakteryzowane w modelu. Następnie projektanci modeli baz danych mogą dodać więcej szczegółów, takich jak informacje, które chcą przechowywać na temat encji i relacji, które są atrybutami oraz wszelkie ograniczenia dotyczące encji, relacji i atrybutów. Modelowanie ER jest ważną techniką do opanowania przez każdego projektanta baz danych i stanowi podstawę metodologii.

Typ encji: Jest to grupa obiektów o tych samych właściwościach, które są identyfikowane przez przedsiębiorstwo jako posiadające niezależne istnienie. Podstawowym pojęciem modelu ER jest typ encji, który jest używany do reprezentowania grupy „obiektów” w „świecie rzeczywistym” o tych samych właściwościach. Typ encji ma niezależne istnienie w bazie danych.

Atrybuty są właściwościami encji, które są reprezentowane za pomocą figur w kształcie elipsy. Każda figura eliptyczna reprezentuje jeden atrybut i jest bezpośrednio połączona ze swoją encją (która jest reprezentowana jako prostokąt).

Typ relacji jest zbiorem skojarzeń pomiędzy jednym lub więcej uczestniczącymi typami encji. Każdemu typowi relacji nadawana jest nazwa, która opisuje jego funkcję. Istnieją cztery typy relacji. Są to:

  • Jeden do jednego: Kiedy tylko jedna instancja encji jest związana z relacją, jest ona określana jako '1:1′.
  • One-to-many: Kiedy więcej niż jedna instancja podmiotu jest powiązana i połączona z relacją, jest to określane jako '1:N’.
  • Many-to-one: Kiedy więcej niż jedna instancja podmiotu jest powiązana z relacją, jest to określane jako 'N:1′.
  • Many-to-many: Kiedy więcej niż jedna instancja podmiotu po lewej stronie i więcej niż jedna instancja podmiotu po prawej stronie może być połączona z relacją, wtedy jest to określane jako relacja N:N.

Oto kilka przykładów:

Jeden do jednego

KonektorERD: jeden do jednego

Jeden do wielu

KonektorERD: jeden do wielu (jeden lub więcej)

Wielu do wielu

KonektorERD: jeden do wielu

Jeden do zera lub wielu

KonektorERD: wielu do wielu

Modele danych: Projekt koncepcyjny / logiczny i fizyczny

ER Modeling rozpoznaje trzy różne poziomy abstrakcji, na których tworzone są modele. Trzy poziomy modelowania danych, koncepcyjny model danych, logiczny model danych i fizyczny model danych.

Modele koncepcyjne, logiczne i fizyczne lub ERD są trzema różnymi sposobami modelowania danych w domenie. Podczas gdy wszystkie zawierają encje i relacje, różnią się one celami, dla których są tworzone i odbiorcami, do których są skierowane. Ogólne rozumienie tych trzech modeli jest takie, że analityk biznesowy używa modelu konceptualnego i logicznego do modelowania danych wymaganych i produkowanych przez system pod kątem biznesowym, podczas gdy projektant baz danych udoskonala wczesny projekt, aby wyprodukować model fizyczny do przedstawienia fizycznej struktury bazy danych gotowej do budowy bazy danych.

Tutaj porównujemy te trzy typy modeli danych. Poniższa tabela porównuje ich różne cechy:

Koncepcyjny: Model koncepcyjny powinien być skoncentrowany na rzeczach związanych z biznesem i jego wymaganiami. Jest on zbierany z wymagań biznesowych. Entities i relacje modelowane w takim ERD są definiowane wokół potrzeb biznesu. Potrzeba zaspokojenia projektu bazy danych nie jest jeszcze brana pod uwagę. Konceptualny ERD jest najprostszym modelem spośród wszystkich.

Przykład koncepcyjnego ERD

Logiczny: Model logiczny powinien być skoncentrowany na projektowaniu danych o tych rzeczach, ale bez odniesienia do konkretnej fizycznej implementacji. Jest on bardziej złożony niż model konceptualny w tym sensie, że ustawiane są typy kolumn. Zauważ, że ustawienie typów kolumn jest opcjonalne, a jeśli to zrobisz, powinieneś to zrobić, aby pomóc w analizie biznesowej. Nie ma to jeszcze nic wspólnego z tworzeniem bazy danych.

Przykład logicznego ERD

Fizyczny: Model fizyczny powinien skupiać się na tym, w jaki sposób dane logiczne powinny być reprezentowane i przechowywane w konkretnej fizycznej bazie danych. Reprezentuje on rzeczywisty projekt relacyjnej bazy danych. Reprezentuje on sposób, w jaki dane powinny być uporządkowane i powiązane w konkretnym DBMS, dlatego ważne jest, aby podczas projektowania fizycznego ERD wziąć pod uwagę konwencję i ograniczenia DBMS, z którego korzystamy. Oznacza to, że konieczne jest dokładne użycie typu danych dla kolumn encji oraz unikanie używania słów zarezerwowanych w nazewnictwie encji i kolumn. Poza tym, projektanci baz danych mogą również dodawać klucze podstawowe, klucze obce i ograniczenia do projektu.

Przykład fizycznego ERD

Przykład – zapisy studentów

Ogólne zrozumienie trzech modeli danych jest takie, że analityk biznesowy używa modelu konceptualnego i logicznego do modelowania obiektów biznesowych istniejących w systemie, podczas gdy projektant bazy danych lub inżynier bazy danych rozwija konceptualny i logiczny model ER w celu stworzenia modelu fizycznego, który przedstawia fizyczną strukturę bazy danych gotową do utworzenia bazy danych. Poniżej znajduje się kolejny przykład ilustrujący 3 różne poziomy modelu danych.

Koncepcyjny model danych

Przykład koncepcyjnego modelu danych: zapisy studentów

Logiczny model danych

Przykład logicznego modelu danych: student enrolment

Physical Data Model

Przykład fizycznego modelu danych: student enrolment

Comparing Conceptual / Logical and Physical ER Model

While all the three levels of an ER model contain entities with attributes and relationships, they differ in the purposes they are created for and the audiences they are meant to target. The table below shows the difference between the three data models.

ERD features Conceptual Logical Physical
Entity (Name) Yes Yes Yes
Relationship Yes Yes Yes
Columns Yes Yes
Column’s Types Optional Yes
Primary Key Yes
Foreign Key Yes