Mi az adatmodellezés?

Az adatmodellezés az a folyamat, amelynek során egy diagramot (pl. ERD) az adatbázisban tárolni kívánt különböző típusú információk közötti kapcsolatokról, amely segít szisztematikusan gondolkodni a tárolni és visszakeresni kívánt kulcsfontosságú adatpontokról, valamint arról, hogyan kell azokat csoportosítani és egymáshoz kapcsolni, ez az, amit a

Az adatmodell az információkat olyan szisztematikus módon írja le, amely lehetővé teszi azok hatékony tárolását és visszakeresését egy relációs adatbázisrendszerben, amelyet úgy lehet elképzelni, mint a valós világban lévő dolgok és a köztük lévő kapcsolatok pontos leírásának logikáját olyan szabályokba fordítani, amelyeket a számítógépes kód követni és érvényesíteni tud. Az adatmodellezés egyik célja, hogy az információk tárolásának leghatékonyabb módszerét hozza létre, miközben teljes körű hozzáférést és jelentéstételt biztosít.

Entity Relationship Diagram for Data Modeling

A kezdetben Peter Chen által 1976-ban javasolt Entity Relationship Diagram (ERD) az adatmodellezés vizuális ábrázolása szimbólumok és jelölések segítségével, amelyek leírják, hogy ezek az adatok hogyan kapcsolódnak egymáshoz. Az adatbázis-fejlesztők közvetlenül használhatják az adatok konkrét szoftveralkalmazásokban történő megvalósításának tervrajzaként. Az ER-diagram segítségével bármilyen objektum, például az entitások, az entitás attribútumai, a kapcsolat halmazai és a kapcsolat egyéb attribútumai jellemezhetők.

Az ERD lehetővé teszi az olvasók számára, hogy hatékonyan megértsék a különböző mezők közötti kapcsolatot. A szimbólumok az információk hatékony ábrázolására szolgálnak, és segítenek az adatbázis működésének megértésében is. Az ER-diagramok egy nagyon hasznos adatmodellezési technikát jelentenek, amely magában foglalja:

  1. Az ER-diagramok könnyen érthetőek, és nem igényel széleskörű képzést ahhoz, hogy valaki hatékonyan és pontosan tudjon velük dolgozni. Ez azt jelenti, hogy a tervezők az ER-diagramok segítségével könnyen kommunikálhatnak a fejlesztőkkel, ügyfelekkel és végfelhasználókkal, függetlenül azok informatikai jártasságától.
  2. Az ER-diagramok könnyen lefordíthatók relációs táblázatokra, amelyekből gyorsan építhetők adatbázisok.
  3. Az ERD-diagramok más összefüggésekben is alkalmazhatók, például egy szervezeten belüli különböző kapcsolatok és műveletek leírására.

Az ERD elemei

Az ERD-modellezés az adatbázis-tervezés felülről lefelé irányuló struktúrája, amely az entitásoknak és kapcsolatoknak nevezett fontos adatok azonosításával kezdődik a modellben jellemzendő adatokkal együtt. Ezután az adatbázis-modell tervezői további részleteket adhatnak hozzá, például az entitásokról és kapcsolatokról tárolni kívánt információkat, amelyek az attribútumok, valamint az entitásokra, kapcsolatokra és attribútumokra vonatkozó esetleges korlátozások. Az ER-modellezés fontos technika, amelyet minden adatbázis-tervezőnek el kell sajátítania, és ez képezi a módszertan alapját.

Egységtípus: Azonos tulajdonságokkal rendelkező objektumok csoportja, amelyeket a vállalkozás független létezőként azonosít. Az ER-modell alapfogalma az entitástípus, amelyet a “valós világban” azonos tulajdonságokkal rendelkező “objektumok” csoportjának ábrázolására használnak. Egy entitás típus önálló létezéssel rendelkezik egy adatbázisban.

Az attribútumok az entitások tulajdonságai, amelyeket ellipszis alakú ábrákkal ábrázolunk. Minden ellipszis alakú ábra egy attribútumot képvisel, és közvetlenül kapcsolódik a hozzá tartozó (téglalapként ábrázolt) entitáshoz.

A kapcsolattípus egy vagy több résztvevő entitás típus közötti asszociációk összessége. Minden kapcsolattípusnak van egy neve, amely leírja a funkcióját. Négyféle kapcsolattípus létezik. Ezek a következők:

  • Egy-az-egyhez: Ha egy entitásnak csak egyetlen példánya kapcsolódik a kapcsolathoz, akkor azt “1:1”-nek nevezzük.
  • Egy-többhöz: Amikor egy entitás több mint egy példánya kapcsolódik és kapcsolódik egy kapcsolathoz, akkor azt “1:N”-nek nevezzük.
  • Many-to-one: Amikor egy entitás több mint egy példánya kapcsolódik a kapcsolathoz, azt “N:1”-nek nevezzük.
  • Many-to-many: Amikor egynél több baloldali és egynél több jobboldali entitáspéldány köthető a kapcsolattal, akkor azt N:N kapcsolatnak nevezzük.

Itt van néhány példa:

Egy az egyhez

ERD csatlakozó: egy az egyhez

Egy a sokhoz

ERD csatlakozó: Egy a sokhoz (egy vagy több)

Sok a sokhoz

ERD csatlakozó: egy a sokhoz

Egy a nullához vagy sokhoz

ERD csatlakozó: sok a sokhoz

Adatmodellek: Koncepcionális / logikai és fizikai tervezés

AzER modellezés három különböző absztrakciós szintet ismer fel, amelyeken a modellek kidolgozása történik. Az adatmodellezés három szintje, a fogalmi adatmodell, a logikai adatmodell és a fizikai adatmodell.

A fogalmi, logikai és fizikai modellek vagy ERD az adatok modellezésének három különböző módja egy tartományban. Bár mindegyik tartalmaz entitásokat és kapcsolatokat, különböznek a céljuk és a célközönségük tekintetében. A három modell általános értelmezése az, hogy az üzleti elemző a konceptuális és logikai modellt a rendszer által igényelt és előállított adatok üzleti szempontból történő modellezésére használja, míg az adatbázis-tervező a korai tervezést finomítja a fizikai modell előállításához az adatbázis-építésre kész fizikai adatbázis-struktúra bemutatásához.

Az alábbiakban az adatmodellek e három típusát hasonlítjuk össze. Az alábbi táblázat a különböző jellemzőket hasonlítja össze:

Konceptuális: A konceptuális modellnek az üzleti tevékenységgel és annak követelményeivel kapcsolatos dolgokra kell összpontosítania. Az üzleti követelményekből gyűjtött. Az ilyen ERD-ben modellezett entitások és kapcsolatok az üzleti igények körül kerülnek meghatározásra. Az adatbázis-tervezés kielégítésének igényét még nem veszik figyelembe. A koncepcionális ERD a legegyszerűbb modell az összes közül.

Koncepcionális ERD példa

Logikai: A logikai modellnek az adott dolgokról szóló adatok megtervezésére kell összpontosítania, de konkrét fizikai megvalósításra való hivatkozás nélkül. Összetettebb, mint a fogalmi modell, mivel oszloptípusok vannak beállítva. Vegye figyelembe, hogy az oszloptípusok beállítása opcionális, és ha ezt megteszi, akkor azt az üzleti elemzés elősegítése érdekében kell tennie. Az adatbázis létrehozásához még semmi köze.

Logikai ERD példa

Fizikai: A fizikai modellnek arra kell összpontosítania, hogy a logikai adatokat hogyan kell ábrázolni és tárolni egy adott fizikai adatbázisban. Ez egy relációs adatbázis tényleges tervezési tervét jelenti. Azt mutatja be, hogy az adatokat hogyan kell strukturálni és összekapcsolni egy adott DBMS-ben, ezért fontos, hogy a fizikai ERD tervezésekor figyelembe vegye az Ön által használt DBMS konvencióit és korlátait. Ez azt jelenti, hogy az entitások oszlopaihoz az adattípus pontos használata szükséges, és az entitások és oszlopok elnevezésénél kerülni kell a fenntartott szavak használatát. Emellett az adatbázis-tervezők elsődleges kulcsokat, idegen kulcsokat és korlátozásokat is hozzáadhatnak a tervezéshez.

Fizikai ERD példa

Példa – Diákbeiratkozás

A három adatmodell általános értelmezése szerint az üzleti elemző fogalmi és logikai modellt használ a rendszerben létező üzleti objektumok modellezésére, míg az adatbázis-tervező vagy adatbázis-mérnök a fogalmi és logikai ER modellt dolgozza ki a fizikai modell létrehozásához, amely az adatbázis létrehozására kész fizikai adatbázis-struktúrát mutatja be. Íme egy másik példa az adatmodell 3 különböző szintjének szemléltetésére.

Konceptuális adatmodell

Konceptuális adatmodell példa: Diákbeiratkozás

Logikai adatmodell

Logikai adatmodell példa:Fizikai adatmodell

Fizikai adatmodell példa: 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