Data

Converting conceptual/logical to physical data model

It’s easy to find information on the Internet about what a relational database is, what relationships exist, what is normalization. In this article, I will try to raise the subject of the conceptual data model and its conversion into a physical model. Some students will find this knowledge useful in completing the database subject in college ­čśŐ // Wersja po polsku pod wersj─ů angielsk─ů

Conceptual data model

When approaching the modeling of a section of a certain area that will concern our project, we start from a high level of abstraction. In the conceptual model, we try to identify entities and relationships between them. We do it based on customer requirements for the system being manufactured.
This model is a business look at the data in the produced system. There are no details related to the physical software / platform on which data will be available. A poorly chosen data model will be vindicated in the later stages of the software development process.

Physical data model

The physical data model is a database project. The table structure, relations, names, attributes, keys and indexes will be exactly as in the database. Conversion to a physical data model is most often done with tools such as Power Designer or Visual Paradigm.

We can distinguish three relationships: one to one, one to many and many to many. Let’s see what happens to the keys when we move from a conceptual / logical diagram to a physical one. I will demonstrate this using the Power Designer tool with simple examples. Physical models will be generated under MS SQL.

One-to-one

Suppose a student can have one card assigned. In the first case, the Student.Card entity will not have the primary key.


In the physical model, the StudentId primary key is now a foreign key in Student.Card

In the second case Student.Card has its main key.

Which results in each table having a foreign neighbor’s key.

However, when we indicate that the Student entity is dominant:

Only one foreign key will occur. StudentId will be foreign key in the Student.Card table

One to Many

In this case, let’s assume that the student must belong to one of the groups, and the conceptual diagram looks like this:

The Student.Student table will contain the GroupId foreign key.

Let’s consider (apart from the reasonableness) when the relationship between the student and the group will be dependent. In this case, the entity is partially identified by another entity.

The Student.Student will take the GroupId key which will be both the main and foreign key. It should be remembered that now the StudentId and GroupId key pair identifies this entity. In the case of a more extensive model, this pair may be a foreign key in another table.

Many to many

Consider the case when a student can be in multiple groups at once.

In the case of many-to-many relationships, an intersection is created that contains foreign keys of both the Student and Group tables. Often, such a table is already created in the conceptual model with necessary attributes related to the domain or technical ones like creation date.

Wersja Polska

┼üatwo znale┼║─ç informacje w Internecie na temat czym jest relacyjna baza danych, jakie relacje wyst─Öpuj─ů, co to jest normalizacja. W tym artykule postaram si─Ö poruszy─ç temat konceptualnego modelu danych oraz jego konwersji na model fizyczny. Niejednej osobie wiedza ta przyda si─Ö w zaliczeniu przedmiotu ÔÇ×Bazy DanychÔÇŁ na studiach ­čśŐ

Konceptualny model danych

Gdy podchodzimy do modelowania wycinka pewnej dziedziny której będzie dotyczył nasz projekt, zaczynamy od wysokiego poziomu abstrakcji. W modelu konceptualnym staramy się zidentyfikować encje oraz relacje między nimi. Robimy to na podstawie wymagań klienta do wytwarzanego systemu.
Model ten jest spojrzeniem biznesowym na dane w wytwarzanym systemie. Nie ma w nim ┼╝adnych detali zwi─ůzanych z fizycznym oprogramowaniem/platform─ů na kt├│rej b─Öd─ů dane. ┼╣le dobrany model danych b─Ödzie m┼Ťci┼é si─Ö w p├│┼║niejszych fazach procesu wytwarzania oprogramowania.

Fizyczny model danych

Fizyczny model danych jest to projekt KONKRETNEJ bazy danych. Struktura tabel, relacje, nazwy, atrybuty, klucze i indeksy b─Öd─ů dok┼éadnie takie jak w bazie danych. Konwersja do fizycznego modelu danych najcz─Ö┼Ťciej wykonywana jest narz─Ödziami takimi jak Power Designer lub Visual Paradigm.

Mo┼╝emy wyr├│┼╝ni─ç 3 relacje: jeden do jednego, jeden do wielu oraz wiele do wielu. Zobaczmy co stanie si─Ö z kluczami gdy b─Ödziemy przechodzi─ç z diagramu konceptualnego/logicznego na fizyczny. Zademonstruj─Ö to przy u┼╝yciu narz─Ödzia Power Designer na prostych przyk┼éadach. Modele fizyczne b─Öd─ů generowane pod MS SQL

Jeden-do-jednego

Za┼é├│┼╝my, ┼╝e student mo┼╝e mie─ç przypisan─ů jedn─ů kart─Ö. W pierwszym przypadku encja Student.Card nie b─Ödzie mia┼éa klucza g┼é├│wnego.


W modelu fizycznym klucz główny StudentId jest teraz kluczem obcym w Student.Card

W drugim przypadku Student.Card ma swój klucz główny.

Co skutkuje tym, ┼╝e ka┼╝da tabela posiada klucz obcy s─ůsiada.

Jednak gdy wska┼╝emy, ┼╝e encja Student jest dominuj─ůca

Wyst─ůpi tylko jeden klucz obcy. StudentId b─Ödzie kluczem obcym w tabeli Student.Card

Jeden-do-wielu

W tym przypadku za┼é├│┼╝my, ┼╝e student musi nale┼╝e─ç do jednej z grup, a diagram konceptualny wygl─ůda tak:

W zwi─ůzku z czym , w tabeli Student.Student znajdzie si─Ö klucz obcy GroupId

W drugim przypadku rozpatrzmy (pomijaj─ůc sensowno┼Ť─ç) gdy relacje mi─Ödzy studentem i grup─ů b─Ödzie zale┼╝na. W takim przypadku encja jest cz─Ö┼Ťciowa identyfikowana przez inn─ů.

W tym przypadku do tabeli Student.Student przejdzie klucz GroupId kt├│ry b─Ödzie jednocze┼Ťnie kluczem g┼é├│wnym i obcym. Nale┼╝y pami─Öta─ç, ┼╝e teraz para kluczy StudentId i GroupId identyfikuje t─ů encj─Ö. W przypadku bardziej rozbudowanego modelu, para ta mo┼╝e by─ç kluczem obcym w innej tabeli.

Wiele-do-wielu

Rozwa┼╝my przypadek gdy student mo┼╝e by─ç w wielu grupach naraz.

W przypadku relacji wiele do wielu, powstaje intersekcja, kt├│ra zawiera klucze obce obu tabeli Student i Group. Cz─Östo tak─ů tabel─Ö tworzy si─Ö ju┼╝ w modelu konceptualnym i dodaje potrzebne atrybuty zwi─ůzane z domen─ů lub techniczne typu data utworzenia.

1
Leave a Reply

Please Login to comment
  Subscribe  
newest oldest most voted
Notify of
trackback

[EN] Converting conceptual/logical to physical data model – mSzymczyk Blog

Dzi─Ökujemy za dodanie artyku┼éu – Trackback z dotnetomaniak.pl