Normalisierung in Datenbanken (1. bis 3. Normalform)

Summary

Dieses Video behandelt die Normalisierung in Datenbanken, die notwendig ist, um Anomalien in relationalen Datenbanken zu vermeiden. Es wird erklärt, dass Daten in der Null-Normalform in einer Tabelle unnormalisiert sind und dann nach den Regeln der ersten Normalform in atomare Attribute unterteilt werden. Weiterhin wird gezeigt, wie man mit der zweiten Normalform Tabellen erzeugt, die sicherstellen, dass jedes Nicht-Schlüsselattribut vollständig funktional von jedem Schlüssel abhängt. Es werden auch Begriffe wie Primärschlüssel und Fremdschlüssel erklärt und wie 1:n und n:n Beziehungen in relationalen Datenbanken modelliert werden.

Takeaways

• 😀 Normalisierung ist notwendig, um Anomalien in relationalen Datenbanken zu vermeiden.
• 🔍 Es gibt strenge Regeln für die Normalisierung, die befolgt werden müssen, um Datenbanktabellen in verschiedenen Normalformen zu erreichen.
• 📚 Die Nullte Normalform (0NF) bedeutet, dass alle Daten in einer einzigen Tabelle unnormalisiert sind.
• 📈 Die Erste Normalform (1NF) wird erreicht, wenn alle Attributwerte atomar sind und keine Teilbarkeiten mehr vorliegen.
• 🔑 Die Zweite Normalform (2NF) erfordert, dass die Tabelle in 1NF ist und jedes Nicht-Schlüsselattribut vollständig funktional von jedem Kandidatenschlüssel abhängig ist.
• 🔗 In relationalen Datenbanken wird ein Primärschlüssel verwendet, um ein Datenset eindeutig zu identifizieren.
• 📊 Die Erstellung von Untertabellen hilft, die Anforderungen der 2NF zu erfüllen, indem nicht-schlüsselbezogene Daten in separate Tabellen ausgelagert werden.
• 🔄 Die Beziehungen zwischen Tabellen, wie 1:n oder n:m, werden durch Fremdschlüssel und zusätzliche Tabellen modelliert, um die Normalformen zu gewährleisten.
• 📝 Die Erklärung der Normalformen hilft, Datenredundanzen und Anomalien zu vermeiden und die Datenintegrität beizubehalten.
• 💡 Die Anwendung der Normalisierungsregeln ist ein wichtiger Schritt im Datenbankdesign, um die Effizienz und Zuverlässigkeit der Datenspeicherung zu verbessern.

Q & A

Was ist Normalisierung in der Datenbank-Design?

Normalisierung ist ein Prozess im Datenbank-Design, der darauf abzielt, Anomalien in relationalen Datenbanken zu vermeiden, indem Daten redundant und gut strukturiert gespeichert werden.

Welche Art von Anomalien werden durch Normalisierung vermieden?

Durch Normalisierung werden Anomalien wie Update-Anomalien, Einfüge-Anomalien und Löschanomalien vermieden, die auftreten können, wenn Daten nicht korrekt in einer Datenbank organisiert sind.

Was ist die Bedeutung von 'atomaren' Attributwerten in Bezug auf die erste Normalform?

In der ersten Normalform (1NF) müssen alle Attributwerte atomar sein, d.h., sie dürfen nicht weiter in kleinere Bestandteile unterteilt werden, um eine konsistente und redundantenfreie Datenstruktur zu gewährleisten.

Wie wird die erste Normalform erreicht?

Um eine Tabelle in die erste Normalform zu bringen, müssen alle Attributwerte atomar sein und die Tabelle darf keine zusammengesetzten Attributgruppen enthalten, die in mehrere Spalten aufgeteilt werden müssen.

Was ist die Bedeutung von 'Schlüsselkandidaten' in der zweiten Normalform?

Schlüsselkandidaten sind Attribute oder eine Kombination von Attributen, die genutzt werden können, um eindeutig Datensätze in einer Tabelle zu identifizieren. Sie sind entscheidend für die Erreichung der zweiten Normalform (2NF).

Was bedeutet es, wenn eine Tabelle in der zweiten Normalform ist?

Eine Tabelle ist in der zweiten Normalform, wenn sie die Bedingungen der ersten Normalform erfüllt und jedes Nicht-Schlüsselattribut vollständig funktional von jedem Schlüsselkandidaten abhängig ist.

Wie wird die Beziehung zwischen Tabellen in relationalen Datenbanken dargestellt?

In relationalen Datenbanken werden Beziehungen durch Fremdschlüssel dargestellt. Ein Fremdschlüssel in einer Tabelle verweist auf den Primärschlüssel einer anderen Tabelle, um die Verbindung zwischen den Tabellen herzustellen.

Was ist eine 1:n-Beziehung in relationalen Datenbanken?

Eine 1:n-Beziehung (eins-zu-vielen) bedeutet, dass ein Datensatz in der Haupttabelle (z.B. ein Kunde) mehrere zugehörige Datensätze in der verknüpften Tabelle haben kann (z.B. mehrere Bestellungen), während ein Datensatz in der verknüpften Tabelle nur einem Datensatz in der Haupttabelle zugeordnet werden kann.

Was ist eine n:n-Beziehung und wie wird sie in relationalen Datenbanken gehandhabt?

Eine n:n-Beziehung (vielen-zu-vielen) bedeutet, dass ein Datensatz in einer Tabelle (z.B. ein Artikel) mehrere Datensätze in einer anderen Tabelle haben kann (z.B. mehrere Bestellungen) und umgekehrt. Um diese Beziehung zu verwalten, wird eine neue Tabelle erstellt, die Fremdschlüssel von beiden Tabellen als zusammengesetzten Primärschlüssel enthält.

Was sind die Schritte, um eine Tabelle in die dritte Normalform zu bringen?

Um eine Tabelle in die dritte Normalform zu bringen, muss die Tabelle bereits in der zweiten Normalform sein und jedes Nicht-Schlüsselattribut muss nur von dem Primärschlüssel und nicht von einem Teil des Primärschlüssels abhängen.

Was ist der Zweck von Normalisierung in Datenbanken?

Der Zweck der Normalisierung in Datenbanken ist es, redundanzfreie, gut organisierte und leicht zu verwaltende Datenstrukturen zu schaffen, die es ermöglichen, Datenanomalien zu vermeiden und die Datenintegrität zu gewährleisten.

Outlines

00:00

😀 Datenbanknormalisierung Einführung

Dieses Video behandelt das Thema der Datenbanknormalisierung, die notwendig ist, um Anomalien in relationalen Datenbanken zu vermeiden. Es wird auf ein bereits veröffentlichtes Video verwiesen, das Anomalien und ihre Probleme erklärt. Die Normalisierung dient der Datenbankgestaltung und soll Anomalien und Redundanzen verhindern. Der Einstieg erfolgt mit der Nullten Normalform, die durch eine Tabelle ohne Normalisierung gekennzeichnet ist. Das Beispiel der Computerfirma HyperEDV zeigt, wie Daten in einer Tabelle zusammengefasst werden. Die Umwandlung in die Erste Normalform erfordert, dass alle Attributwerte atomar sind, was bedeutet, dass sie nicht weiter zerlegt werden können. Beispielsweise müssen der Name in Vor- und Nachname aufgeteilt werden, um eine effiziente Sortierung und Filterung zu ermöglichen.

05:00

📚 Von der Nullten zur Ersten Normalform

Die Umwandlung der Datenbanktabelle in die Erste Normalform beinhaltet die Trennung von zusammengefassten Attributen in atomare Bestandteile. Hierbei wird die Adresse beispielsweise in Straße, Ort und Postleitzahl aufgeteilt, um eine klare Zuordnung und effiziente Datenverwaltung zu gewährleisten. Es wird betont, dass die Trennung so weitgehend wie möglich durchgeführt werden muss, ohne jedoch unnötige Unterteilungen vorzunehmen, die keine praktischen Vorteile bringen, wie etwa die Trennung der Hausnummer, wenn diese für keine weitere Verwendung erforderlich ist.

10:04

🔑 Die Zweite Normalform und Schlüssel

Der zweite Abschnitt des Skripts konzentriert sich auf die Zweite Normalform, die die Bedingung aufstellt, dass jeder Nicht-Schlüsselattribut vollständig funktional abhängig vom Schlüsselkandidaten sein muss. Hierbei wird erläutert, dass jede höhere Normalform auf der vorherigen basiert und dass die Erstellung von Primärschlüsseln in relationalen Datenbanken dazu dient, Datensätze eindeutig zu identifizieren. Durch die Trennung in verschiedene Tabellen, wie z.B. Kunden, Bestellungen und Artikelnummer, werden die Beziehungen zwischen den Daten klarer und die Datenintegrität gewährleistet. Die Verwendung von zusammengesetzten Primärschlüsseln in der Tabelle 'OrderArticle' verdeutlicht die Notwendigkeit, beide Informationen zusammen zu betrachten, um sinnvolle Daten zu erhalten.

🔗 Beziehungen in relationalen Datenbanken

Dieses Kapitel erklärt die Beziehungen zwischen Tabellen in relationalen Datenbanken, insbesondere die 1:n-Beziehung zwischen Kunden und Bestellungen sowie die n:n-Beziehung zwischen Artikeln und Bestellungen. Es wird verdeutlicht, wie durch die Verwendung von Fremdschlüsseln in der Bestellungen-Tabelle die 1:n-Beziehung zwischen Kunden und ihren Bestellungen modelliert wird. Für die n:n-Beziehung wird die Notwendigkeit einer neuen Tabelle hervorgehoben, die die Beziehung zwischen Artikeln und Bestellungen abbildet und somit die Flexibilität und Effizienz der Datenbank erhöht.

Keywords

💡Normalisierung

Normalisierung ist ein Prozess im Datenbankdesign, der darauf abzielt, Anomalien in relationalen Datenbanken zu vermeiden. Im Video wird erläutert, dass sie dazu beiträgt, Redundanzen und inkonsistente Daten zu reduzieren. Ein Beispiel dafür ist die Umwandlung von Daten in der dritten Normalform, um sicherzustellen, dass jeder Datenwert genau einmal vorkommt und vollständig funktional von den Schlüsseln abhängt.

💡Anomalie

Anomalien beziehen sich auf Probleme, die in nicht normalisierten Datenbanken auftreten können, wie z.B. Datenredundanz, Datenverlust und inkonsistente Daten. Im Video wird erklärt, dass Normalisierung dazu dient, solche Anomalien zu vermeiden, indem Daten in eine formale Struktur gebracht werden, die diese Probleme reduziert.

💡Zero Normalform

Die Zero Normalform (0NF) ist ein Ausgangspunkt in der Datenbank-Normalisierung, bei dem alle Daten in einer einzigen Tabelle gespeichert sind, ohne besondere Struktur. Im Video wird die HyperEDV-Datenbank als Beispiel verwendet, um zu zeigen, wie Daten in der 0NF unstrukturiert sind und wie sie in die erste Normalform konvertiert werden müssen.

💡Erste Normalform

Die erste Normalform (1NF) erfordert, dass alle Attribwerte atomar sind, d.h., sie können nicht weiter in kleinere Bestandteile unterteilt werden. Im Video wird gezeigt, wie die Tabelle von der 0NF in die 1NF transformiert wird, indem z.B. der Name in Vor- und Nachname aufgeteilt wird, um die Sortierung und Suche nach Kunden zu erleichtern.

💡Atomar

Atomarität bezieht sich auf die Eigenschaft von Attribwerten, die nicht weiter in kleinere Einheiten unterteilt werden können. Im Video wird dies anhand des Beispiels des Namens-Attributs veranschaulicht, das in Vor- und Nachname aufgeteilt wird, um die Atomarität zu erreichen.

💡Zweite Normalform

Die zweite Normalform (2NF) erfordert, dass eine Tabelle in 1NF ist und jedes Nichtschlüsselattribut vollständig funktional von jedem Schlüsselkandidaten abhängt. Im Video wird erklärt, wie durch die Trennung von Tabellen, z.B. in Kunden-, Aufträge- und Artikeltabellen, sichergestellt wird, dass die 2NF-Regeln erfüllt sind.

💡Schlüsselkandidaten

Schlüsselkandidaten sind Attribute oder eine Kombination von Attributen, die verwendet werden können, um eindeutig Datensätze in einer Tabelle zu identifizieren. Im Video wird gezeigt, wie z.B. die Kundennummer, Artikelnummer und Auftragsnummer als Schlüsselkandidaten für die jeweiligen Tabellen fungieren.

💡Primärschlüssel

Ein Primärschlüssel ist ein Schlüsselkandidaten, der als eindeutige Identifikation für Datensätze in einer Tabelle verwendet wird. Im Video wird erläutert, dass Primärschlüssel, wie z.B. die Kundennummer, nur einmal vorkommen dürfen und somit die Eindeutigkeit der Datensätze gewährleisten.

💡Fremdschlüssel

Ein Fremdschlüssel ist ein Schlüssel in einer Tabelle, der als Schlüssel in einer anderen Tabelle vorkommt und eine Beziehung zwischen den Tabellen herstellt. Im Video wird beschrieben, wie der Primärschlüssel in der Kundentabelle als Fremdschlüssel in der Auftragstafel verwendet wird, um die 1:n-Beziehung zu repräsentieren.

💡1:n-Beziehung

Eine 1:n-Beziehung (eins-zu-vielen) ist eine Beziehung zwischen Tabellen, bei der ein Datensatz in der Quelltabelle einer beliebigen Anzahl von Datensätzen in der Zieltabelle zugeordnet werden kann. Im Video wird dies anhand der Beziehung zwischen Kunden und Aufträgen veranschaulicht, wobei jede Kundennummer in der Auftragstafel mehrere Aufträge haben kann.

💡n:m-Beziehung

Eine n:m-Beziehung (vielen-zu-vielen) ist eine Beziehung, bei der Datensätze in beiden Tabellen mehreren Datensätzen in der jeweils anderen Tabelle zugeordnet werden können. Im Video wird erklärt, dass für eine n:m-Beziehung, wie die zwischen Aufträgen und Artikeln, eine neue Tabelle benötigt wird, um diese Beziehung zu verwalten.

Highlights

The video discusses the concept of normalization in databases to prevent anomalies.

Normalization is a database design technique aimed at avoiding redundancies and anomalies.

The video provides a step-by-step explanation of the normalization rules.

Zeroth normal form is characterized by all data being unnormalized in a single table.

The first normal form requires that all attribute values must be atomic.

Breaking down the 'name' attribute into 'first name' and 'last name' is an example of achieving atomicity.

Addresses should be divided into 'street', 'place', and 'postal zip code' for better database structure.

The importance of distinguishing between atomic and non-atomic data for database efficiency is highlighted.

Second normal form involves ensuring every non-key attribute is fully functionally dependent on the key candidate.

Primary keys are essential for identifying data sets uniquely in relational databases.

The concept of fully functional dependencies is introduced to explain second normal form.

The video demonstrates the creation of four tables to achieve second normal form.

Composite primary keys are used in the 'OrderArticle' table to handle complex relationships.

The necessity of separating non-key attributes into sub-tables for second normal form is explained.

The video clarifies the 1 to n relationship between the 'Customer' and 'Order' tables.

The handling of n to n relationships requires a new table to maintain database integrity.

The video concludes by discussing the practical applications of normalization in database management.

Transcripts

In this video we will deal with the topic of normalization from the field of databases.

Normalization is necessary to avoid anomalies in relational databases.

I have already made a video on this topic, or rather, I have already shown what anomalies

are and what problems they lead to.

I link the video above.

Again and again this leads to problems or difficulties.

But it is enough to remember the rules and just apply them.

I will explain these rules to you step by step.

And it should be said that the normalization is a database design and has the sense to

prevent anomalies and redundancies.

We will start with the zeroth normal form and for this purpose we will

we will look at the database of the computer company hyperEDV, which has a database, but

it is still renormalized.

In a database of the zeroth normal form, all the data is unnormalized in a single table.

And this is exactly the case here.

Our database consists of a single table with order number, name, date of birth, etc..

And as you can see, this doesn't look very good and shouldn't stay that way, which is

why we convert the tables to the first

into the first normal form.

I already said, there are always quite rigid rules for normalization that have to be followed

and the same applies here.

The rule to convert tables into the first normal form is: "All attribute values must

be atomic".

By an

attribute itself we mean a column like OrderNo or the name.

And by atomic we mean that we cannot break down these attributes further.

This is not the case here at the moment, because our table is still in the zeroth normal form

and we are now looking at the name, for example.

Our customers have a first

and a surname and this means that we have to break down these columns as far as possible.

possible.

We make two new columns out of the name column, namely first name and last name.

Because only in this way we can sort by last name at the end and display all customers

who begin with an S in the last name, because our computer would not know if Ludger Sievert

is in a cell, how it should divide the whole thing.

where does the last name begin here, or what is the first name or what is

the last name.

The same still applies to the address.

also the address we would have to divide still into the attributes street, place or postal

zip code, because also the computer does not know, how can one distinguish here between

street, place and postal zip code.

For example, if we display all customers from Münster and

they are in one field, this is not very convenient.

Means; we must divide everything so WIDE that everything in a single column is atomically

in a single column.

And then I would say, let's do that and take a look at the result.

And yes the attentive ones among you will notice now the house number one could divide

nevertheless also still.

Of course you could and that would be absolutely correct according to the rule.

But we neither want to sort by the house number nor do anything with the house number.

That's why it doesn't give us a big advantage.

Here it is of course always a question of weighing up whether it makes sense or not,

but if we were to apply the rule in this way.

Then we would have to transfer the house number of course also in an own column.

So far clear?

The rule is relatively easy to apply.

And we have, if we don't see it strictly, a table in the first

normal form.

We continue this with the second normal form and for this we look as usual first at the

definition which is needed for

the second normal form.

The rule is as follows: A table is in second normal form if it is in first normal form

and every non-key attribute is fully functionally dependent on each key

candidate.

This sounds a bit more complicated than it actually is.

Because it

is not

that complicated at all.

We will notice that now.

As first information is important that each normal form requires the previous

normal form, as with the second one.

Means, if we want to have a table in the second normal form or transfer it to the second the

table must first be in the first first normal form.

And then we can we can bring the table into the second normal form.

This rule is also valid for the third normal form.

Means, there the table must be first in the in the second normal form.

Now let's look further, because for the second

normal form we make a small excursion in relational databases.

In relational databases we work with primary keys.

The purpose of a key in a relational database, a key is used to identify a data set without

identified without any doubt and this value may therefore only occur once.

Our

primary keys can be recognized by the fact that

the columns above are underlined like customer number and

order number are underlined.

For this one or maybe more columns

are defined, which take over this task.

For an order for example we can

we can well imagine the order number for this.

An order has a number and this number

is unique.

It does not exist more than once.

There is nothing to do with it.

The same

applies to the customer and to all articles.

Here, too, the customer number or article number

the article number is unique.

Each customer has its own number and each article has

its own number.

And now we turn our attention to the to the story of the fully functional

dependencies.

We now get a total of four tables as you can see, which have been

created

one table at the beginning.

These are

Order, Customer, Article and OrdersArticle.

We will now look step by step at

why these tables have been created in this form

and how we deal with them.

Each of these

tables in a relational database has a primary key and non-key attributes

which in the second normal form are fully functionally

depend on primary keys.

We look at

at the customer, for example.

Since the first name is fully functionally dependent

to the customer ID.

We can see this even better in the table OrderArticle.

Here we use

we use a composite primary key of order number and article number.

So

both columns form the primary key here.

Order and article must not appear together in this

must not occur again in this table.

In addition there is the column number, which and there one can

you can see it relatively well, equally from the order number as well as from the

article number

as well.

So we always need both information.

So the order number and

the article number together so that the number is meaningful.

That means, the number

is fully functionally dependent to the whole primary key.

So we have each column

that was not fully functionally dependent on a key kanidata

from a key channel data in the previous table into a

sub-table.

We remember, we had our own key candidates, respectively

the article number, customer number and order number

in one table and now we have moved them to

into their own tables, which is normal in the second normal form.

normal form.

Now you ask yourselves

how do we get the second customer number and the second

we get the second customer number and the second

article number and the second order number.

We will now look at this in detail.

Let's have a look at the relationship between the Customer table and

the Order table and the relationship between the table Order, OrderArticle

and Article and the table OrderArticle table.

Let's start first with the order

and the customer and we can see that the customer number

appears in the Order table.

Here

is a relationship between the the Customer table and the Purchase Order

table

and it is a 1 to n

relationship.

The 1 means in this case,

that each order can have one or no customer customer.

And the n means that each customer has not made one or more orders.

orders.

This is resolved in relational databases so that the primary key on the

on the customer side acts as a foreign key in the

Order table.

Thus each

order number can only appear once, since the Order number column is the primary key

and the customer can appear multiple times and can have multiple purchase orders.

Thus we solve

only one to n relationship in relational databases.

databases.

now here we have

a second relationship and this one is a bit more complicated.

Here we are dealing with an

n to n relationship.

If we have a 1 to n relationship, as we have just seen, the primary key

as a foreign key in the other table we need a new table for an

n to n relationship we need a new table in any case.

The n to n relationship says that an item can have

can have several orders and an order can have

several articles