2e normaalvorm (2NF)

[Koffie32]

Ik ga het toch even hier neerleggen want ik krijg het idee dat ik of iets niet begrepen heb in mijn lessen of dat er iets niet klopt in een course die ik nu kijk op Pluralsight.

In de course wordt de bewering gedaan dat om in 2e normaalvorm te staan, aan de volgende eisen moet zijn voldaan:

• Er is al sprake van 1NF.
• Primary keys mogen maar 1 kolom lang zijn (single column primary keys).

Hij breidt dit daarna nog uit door het te omschrijven als: No non-key attribute should be dependent on any proper subset of the key. Vervolgens wijzigd hij alle tabellen uit de casus die een samengestelde primaire sleutel hebben door er een id veld aan toe te voegen met een identity/auto-increment.

Dit is niet wat ik meen te hebben geleerd. Van wat ik weet mag een primary key zo lang zijn als nodig is om een record juist te identificeren. 2NF stelt dat geen attribuut afhankelijk mag zijn van een deel van de primary key en dat als dit zo is dat attribuut moet worden afgesplitst in een eigen tabel.

Ben ik nu gek? Ik begin bijna aan mezelf te twijfelen. Als ik naar het profiel van de persoon zie die de course heeft gemaakt kijkt verwacht ik namelijk dat hij wel weet moet hebben van de materie:

Gerald Britton is a Pluralsight author and expert on Python programming practices and Microsoft SQL Server development and administration. A multiple-year of the Microsoft MVP award, Gerald has led introductory classes in Python and SQL for industry-sponsored events at Ryerson University, Toronto and the University of Toronto (his alma mater).

[Creepy]

Weet je zeker dat je goed leest? Als in 1nf de primary keys daadwerkelijk 1 column zijn, dan is de 1nf al gelijk ook de 2nf. Maar eisen dat in 2nf alle primary keys uit 1 kolom bestaan klopt wat mij betreft ook niet.

[Koffie32]

Creepy schreef op vrijdag 21 augustus 2020 @ 12:29:
Weet je zeker dat je goed leest? Als in 1nf de primary keys daadwerkelijk 1 column zijn, dan is de 1nf al gelijk ook de 2nf. Maar eisen dat in 2nf alle primary keys uit 1 kolom bestaan klopt wat mij betreft ook niet.

Ik weet het vrij zeker dat ik het goed lees.

[Creepy]

En ik lees het als: als je alleen single column primary keys hebt en het staat in 1NF, dan heb je al 2NF en hoef je niks te doen.

[Koffie32]

Creepy schreef op vrijdag 21 augustus 2020 @ 14:01:
En ik lees het als: als je alleen single column primary keys hebt en het staat in 1NF, dan heb je al 2NF en hoef je niks te doen.

code:

CREATE TABLE Orders.Stock (
    StockSKU char(8) NOT NULL,
    StockSize varchar(10) NOT NULL,
    StockName varchar(100) NOT NULL,
    StockPrice numeric(7, 2) NOT NULL,
    CONSTRAINT PK_Stock_StockSKU_StockSize PRIMARY KEY (StockSKU, StockSize)
);

wordt in de demonstratie:

code:

CREATE TABLE Orders.Stock (
    StockID int IDENTITY(1,1) NOT NULL
        CONSTRAINT PK_Stock_StockID PRIMARY KEY,    
    StockSKU char(8) NOT NULL,
    StockSize varchar(10) NOT NULL,
    StockName varchar(100) NOT NULL,
    StockPrice numeric(7, 2) NOT NULL,
);

En nu pas zou hij voldoen aan de regels voor 2NF. Zoals gezegd heb ik hier nog nooit van gehoord.

[MatHack]

Bij twijfel tussen twee bronnen pak je een derde bron erbij en kijk je welke van de twee bronnen 'wint'?
Wikipedia: Databasenormalisatie heeft m.i. duidelijke uitleg + illustratie.

[Creepy]

Koffie32 schreef op vrijdag 21 augustus 2020 @ 14:29:
[...]

En nu pas zou hij voldoen aan de regels voor 2NF. Zoals gezegd heb ik hier nog nooit van gehoord.

Ik ook niet dus

[Koffie32]

MatHack schreef op vrijdag 21 augustus 2020 @ 14:50:
Bij twijfel tussen twee bronnen pak je een derde bron erbij en kijk je welke van de twee bronnen 'wint'?
Wikipedia: Databasenormalisatie heeft m.i. duidelijke uitleg + illustratie.

Ik kijk toch echt liever naar wie de bron is die iets beweert dan naar het aantal bronnen dat hetzelfde zegt. Zeker in deze tijd van filterbubbels.

[Koffie32]

Creepy schreef op vrijdag 21 augustus 2020 @ 15:06:
[...]

Ik ook niet dus

Nog een reactie van de course maker gekregen.

The second rule states that only single-column primary keys are allowed. Well, actually the requirement is stated like this:
“No non-key attributes should be dependent on any proper subset of the key.”
Although it is possible to satisfy this rule with a composite key, if there are no composite keys, then the only proper subset is the empty set. That implies a single-column primary key, which is the standard approach to this problem.

I'm going for the standard approach for SQL Server. Keeping PKs and backing indexes to short, single columns helps with performance and space usage.

In andere bewoordingen. "Ik beweer iets in mijn video dat inderdaad niet klopt maar ik heb het altijd zo gedaan omdat ik het de juiste werkwijze vindt." Ook het fenomeen dat je geen samengestelde sleutel kunt vinden heb ik nog nooit meegemaakt of van gehoord.

Hij betrekt dus database-optimalisatie rechtstreeks in het normalisatieproces. Overigens had ik zelf de indruk dat MS SQL Server deze optimalisatiestap op de achtergrond zelf ook al doet.

[CurlyMo]

In het algemeen heb ik nooit wat van die niveau's van normalisaties begrepen. Misschien dat ik altijd al gevoelsmatig het juiste normalisatie niveau gepakt voor mijn doel. Dat was in ieder geval wat mijn docent database modellen me ooit teruggaf en in mijn werkzame leven ervaar en terug hoor

Het create table voorbeeld wat wordt gegeven behelst wat mij betreft ook veel meer overweging dan alleen de normaalvorm differentiatie.

1. Op welke kolommen wil je snel zoeken en dus evt. geïndexeerd hebben?
2. Welke kolommen moeten unieke waarden bevatten afgedwongen in je database?
3. Welke relaties zijn er tussen tabellen?
4. Hoeveel records zullen de tabellen bevatten?
5. Welke database software wordt er gebruikt?

Afhankelijk van bovenstaande antwoorden is het meer of minder zinnig om bepaalde kolommen een index, primary key, unique en/of een foreign key te maken / geven.

(In PostgreSQL) kan je bijv. best een multikoloms primary key hebben, met daarnaast een single ID unique constraint waar weer een foreign key relatie mee is gemaakt.

[Koffie32]

CurlyMo schreef op zaterdag 22 augustus 2020 @ 09:16:
(In PostgreSQL) kan je bijv. best een multikoloms primary key hebben, met daarnaast een single ID unique constraint waar weer een foreign key relatie mee is gemaakt.

Ik ben nog geen relationele database tegen gekomen die hier geen ondersteuning voor biedt.

[CurlyMo]

Koffie32 schreef op zaterdag 22 augustus 2020 @ 09:40:
[...]

Ik ben nog geen relationele database tegen gekomen die hier geen ondersteuning voor biedt.

Ik ken niet alle relationele database systemen dus ik zeg het voor de zekerheid er altijd maar even bij