sql >> Database teknologi >  >> RDS >> Sqlserver

Databasedesignkoncepter med SQL Server Management Studio (SSMS) del 1

Denne artikel er primært skrevet til begyndere. Alligevel dækker den nogle interessante og ofte glemte databasedesignkoncepter, der er lige så attraktive for SQL-databaseprofessionelle.

Den aktuelle del fokuserer på databasens designkoncepter og deres tilknytning til SQL-databasetabeller, -kolonner og -relationer. Hvis du forstår baggrunden for databaser og værktøjer, vi er ved at bruge, vil du designe din første SQL-database med tillid.

Forudsætninger

Før vi fortsætter, skal du sørge for at have følgende ting:

  1. SQL Server 2016/2017/2019 Express/Developer edition er installeret på din maskine
  2. SSMS (SQL Server Management Studio) er installeret

Du skal også have en grundlæggende viden om databaser og ovenstående værktøjer.

Det er ikke et problem, hvis du ikke har de nyeste SQL Server- og SSMS-versioner. Det anbefales dog stærkt at have de nyere versioner, hvis ikke de seneste tilgængelige. Du kan få de nødvendige versioner fra ressourcerne nedenfor:

  • Download SQL Server 2017 Developer edition.
  • Download SQL Server 2019 (alternativt for at få den seneste SQL Server Express/Developer-udgave).
  • Eller download en gratis specialiseret udgave af Developer eller Express SQL Server.
  • Download SSMS (SQL Server Management Studio)

Bemærk, at disse links alle fungerer fint på tidspunktet for skrivning af denne artikel. Hvis Microsoft beslutter at erstatte dem, skal du downloade den nyere version, der er tilgængelig på det tidspunkt.

Om SQL-databasedesign

For at begynde at designe din SQL-database med SQL Server Management Studio (SSMS), skal du have en designplan i dit sind.

Det er ikke let uden at kende kernekoncepterne for databasedesign. Men når du først har fået disse koncepter og deres implementering, begynder du naturligvis at følge designprincipperne. Det er almindeligt med næsten alle databaseudviklere.

Lad os først gennemgå nogle centrale databasedesignkoncepter. Det er ikke nemt at dække dem alle sammen i én artikel, men vi har brug for noget at starte fra.

Vi forstår en typisk database ud fra følgende ting:

  1. Enheder
  2. Attributter
  3. Relationer

Hvad er en enhed?

En enhed er noget, som virksomheden eller en person gerne vil gemme i en database. For eksempel:

  1. Kunde.
  2. Bestil.
  3. Produkt.

Vi kan sige, at en Kunde er en enhed, hvis virksomheden ønsker at gemme den i en databasestruktur til transaktions-, analyse- og rapporteringsformål. Tilsvarende en Ordre placeret af Kunden er også en enhed, hvis virksomheden ønsker at se disse oplysninger. Derfor skal disse oplysninger være en del af databasen.

Dog en Ordre giver ikke meget mening uden et produkt . Et produkt, der tilbydes til kunden, er også en enhed.

Hvordan er enheden knyttet til databasen?

Fra databaseperspektivet kan en enhed tilknyttes en tabel. Så hvis en virksomhed har brug for kunde-, ordre- og produktenheder, kan databaseudvikleren kortlægge disse som tre tabeller.

Hvad er en egenskab?

En attribut er en beskrivelse af en enhed. For eksempel:

  1. Kundenavn
  2. Ordretype
  3. Produktnavn

Hvis kunden er en enhed, navnet på kunden (Kundenavn ) er en attribut. Denne egenskab beskriver vores enhed (kunde ). Tilsvarende OrderType er en attribut til ordren enhed og Produktnavn er en egenskab for Produktet enhed.

Hvordan er attributten knyttet til databasen?

En attribut, såsom CustomerName, beskriver Kunden tabel og kan tilknyttes en kolonne i den tabel.

En enhed med flere attributter

Det er fint for en enhed at have flere attributter. Derfor kan vi have mange kolonner (attributter) i en tabel (entitet).

Enhedsforhold

En enhed kan relateres til en anden enhed gennem relationer. En tabel kan relateres til en anden tabel. Der er mange typer entiteter eller tabelrelationer:

Kunde-ordreforhold (en-til-mange)

En kunde (enhed/tabel) kan relateres til en ordre (entitet/tabel) af følgende årsager:

  1. En kunde kan afgive én ordre.
  2. En kunde kan afgive mange ordrer.

Det modsatte er også sandt:

  1. Mange ordrer kan afgives af én kunde.
  2. Én ordre kan afgives af én kunde.

Dette er et eksempel på et en-til-mange forhold :én kunde kan afgive mange ordrer, og mange ordrer kan afgives af én kunde.

Produkt-bestillingsforhold (en-til-mange)

Et produkt (entitet/tabel) kan relateres til en ordre (entitet/tabel) på følgende måde:

  1. Et produkt kan tildeles én ordre.
  2. Et produkt kan tildeles mange ordrer.

Tilsvarende:

  1. Mange ordrer kan tildeles et produkt.
  2. En ordre kan have ét produkt.

Der er et en-til-mange forhold mellem Produkt og Bestil .

Kunde-produktforhold (mange-til-mange)

Nu forklares forholdet mellem kunde og produkt som følger:

  1. En kunde kan købe ét produkt.
  2. En kunde kan købe mere end ét produkt.
  3. Et produkt kan købes af en kunde.
  4. Et produkt kan købes af mere end én kunde.

Mange produkter kan købes af mange kunder, hvilket betyder, at Kunden og Produkt forholdet er mange-til-mange .

Tag et kig på illustrationen nedenfor:

Student-Istructor Design Scenario

Lad os overveje et andet databasedesignscenario. Du vil implementere det ved hjælp af SSMS (SQL Server Management Studio) i den anden del af denne artikel.

Forretningskrav

Antag, at du skal designe en database, som gemmer følgende information:

  1. Elev(er).
  2. Instruktør(er).
  3. Elever, der har fået tildelt en instruktør.
  4. Instruktører, der er tildelt eleverne.

Foreløbig analyse

Ved nøje observation vil du opdage noget ganske interessant om ovenstående krav. "De studerende, der har tildelt en instruktør" og "De instruktører, der er blevet tildelt eleverne" er det samme krav.

Det kan være hyppigt, at to forskellige krav viser sig at være ens i forbindelse med databasedesign.

Identificer enheder

Følgende enheder kan straks udvindes fra kravene:

  1. Elev
  2. Instruktør

Men endnu en enhed tjener til at give os oplysninger om de instruktører, der er tildelt eleverne.

Lad os huske det første eksempel, hvor vi brugte en Ordre-tabel - mange kunder kan købe mange ordrer i kunde-ordre-forholdet. Det ligner vores elev-instruktør tabelrelation – mange instruktører kan allokeres til mange elever.

Identificer attributter

Vi kan vælge nyttige attributter for de identificerede enheder i henhold til dette kundeordrescenarie:

  1. Student:Studie-id, navn.
  2. Instruktør:Instruktør-id, navn.
  3. Student-instruktør:Elev-instruktør-id, elev-id, instruktør-id.

Identitetsforhold:

Identificer entitetsrelationerne:

  1. Student -> Elev-instruktør (en-til-mange).
  2. Instruktør-> Elev-instruktør (en-til-mange).
  3. Student -> Instruktør (mange-til-mange).

Husk, at vi altid bruger et mellembord til at løse mange-til-mange forholdet. Det er derfor, vi bragte elev-instruktørenheden ind i planen.

Kortlægning af enheder og attributter til tabeller og kolonner

Nu kan vi kortlægge entiteterne til tabeller. Derfor skal vi oprette følgende tre tabeller:

  1. Elev.
  2. Instruktør.
  3. Student-instruktør.

Tilsvarende vil attributterne for disse entiteter, når de er knyttet til kolonnerne, være som følger:

  1. Student:StudentId, Name.
  2. Instruktør:InstructorId, Name.
  3. Student-instruktør:StudentInstructorId, StudentId, InstructorId.

Bemærk illustrationen nedenfor:

Tillykke! Du har med succes lært databasedesignkoncepterne. Vi er fortrolige med entiteter, attributter og relationer og trinene til at knytte dem til tabeller og kolonner i databasen.

De næste artikler vil lede dig gennem trinene til databasedesign ved hjælp af SSMS (SQL Server Management Studio).

Ting at gøre

Nu hvor du forstår det grundlæggende i databasedesign, kan du prøve følgende ting for at forbedre dine færdigheder yderligere:

  1. Prøv at tilføje en anden enhed kaldet Supplier med attributterne SupplierId og SupplierName. Tjek, om du korrekt kan identificere følgende forhold:
    1. Leverandørordre;
    2. Leverandør-Kunde;
    3. Leverandør-produkt.
  2. Design en database sammen med identificerende enheder, attributter og relationer til et bibliotek. Tip:Bøger udleveres til medlemmerne, og medlemmer låner bøger på biblioteket. Medlem, bog, udstedt kan være enheder.
  3. Identificer typen af ​​følgende tabelrelationer for entiteterne som nævnt ovenfor:
    1. Medlemsudstedt;
    2. Bogudstedt;
    3. Medlemsbog;
    4. Bogmedlem.

Læs også

Lær databasedesign med SQL Server Management Studio (SSMS) – Del 2


  1. Ret "FEJL 1054 (42S22):Ukendt kolonne "..." i "on-klausul" i MariaDB

  2. Sådan opretter du ikke null-begrænsning på kolonne i SQL Server-tabel - SQL Server / T-SQL vejledning del 51

  3. Reduktion af postgresql.conf, parameteren ad gangen

  4. Dupliker rækker i en primær nøgletabel.