Domänmodellering i SAP CAP

Beskrivning

En domänmodell i SAP CAP är en modell som beskriver de statiska, datarelaterade aspekterna av en problemdomän i termer av entitetsrelationsmodeller. I den här artikeln kommer vi att studera domänmodelleringen i SAP CAP i detalj.

Domänmodellering

Med enkla ord, en CDS i SAP CAP producerar en domänmodell på ett sådant sätt att den definierar affärsproblemet i form av nycklar, fält och anteckningar. Koden för att generera en domänmodell skrivs i ett CDS-schema (db/schema.cds). Dessa domänmodeller kan användas i tjänstedefinitioner, persistensmodeller, databaser eller till och med återanvändas inom en annan domänmodell.

Exempelexempel:

Namnutrymme empInfo; använder {Currency, managed} från '@sap/cds/common'; enhet Anställda: hanterad { nyckel-ID: heltal; förnamn: lokaliserad sträng (111); efternamn: lokaliserad sträng (1111); chef: Association to Managers; dateofJoining: Heltal; lön: decimal (9,2); valuta: Valuta; }

 

I det här exemplet har vi skapat en fil schema.cds där vi har skapat en enhet Anställda som innehåller grundläggande detaljer om en Anställd

Hela detta schema har fått ett namnområde, dvs empInfo

Detta schema använder en standarddatatyp, dvs. Valuta. Att använda standarddatatypen som denna hjälper oss att ta med alla fördefinierade värdehjälp relaterade till den.

Vi använder CDS för att skapa en modell. I den CDS använder vi

  1. Entiteter som representerar en uppsättning unika objekt, t.ex.:
    1. Grundläggande information för anställda
    2. Information om anställdas kommunikation
    3. Löneinformation för anställda
  2. Associationer för att definiera relationer
    1. Chefskoppling till en annan enhetschef som kommer att ha alla listan över chefer

Namnkonvention och rekommendationer

  1. Namnet på enheten ska börja med en stor bokstav och det ska vara läsbart och självförklarande – till exempel anställda
  2. Börja element med en liten bokstav – till exempel förnamn
  3. Det rekommenderas att använda pluralform av entiteter – till exempel Anställda
  4. Det rekommenderas att använda singular form av typer – till exempel Valuta
  5. upprepa inte sammanhang – till exempel Employees.name istället för Employees.EmployeeName
  6. föredrar ettordsnamn – till exempel lön istället för lönBelopp
  7. använd ID för tekniska primärnycklar – till exempel ID för medarbetar-ID
  8. Du kan använda Namespace för att göra dina enheter unika. Det är som ett klientkoncept i SAP där du kan ha dubbletter av scheman (cd-filer) med unikt namnområde för att skilja dem åt. Namnutrymmen är valfria, använd namnutrymmen om dina modeller kan återanvändas i andra projekt. I slutet av dagen är de bara prefix, som automatiskt tillämpas på alla relevanta namn i en fil. - till exempel,

namnområde laptop;enhet Dell {}

..… är ekvivalent med:

entity laptop.Dell {}

  1. Du kan använda sammanhang för kapslade namnområdessektioner. - till exempel,

namnområde laptop;enhet Dell {}           //> laptop.Dellsammanhang Apple { enhet MacBookPro {}       //> laptop.Apple.MacBookPro     enhet MacBookAir {} }

 

enheter

Entiteter är som tabeller med primärnycklar. Vi kan utföra CRUD-operationer med dessa Entiteter. Håll den så platt som möjligt. Övernormalisera det inte. Använd inte icke-återanvändbara typer. Det här avsnittet är endast för modellering, endast anteckningar relaterade till enskilda fält ska läggas till och inga tekniska detaljer (logiker) ska läggas till.

Typer

Typer är som Domain i SAP ABAP, det brukade definiera den typ av dataelement.

aspekter

Aspekter är förlängningarna av modellerna och används främst för att utöka befintliga definitioner och kommentarer. När en modell väl har definierats kan vi använda olika cd-filer (Aspect) för att lägga till kommentarer ovanpå dem för specifik uppgift.

Till exempel-

  • cds– din kärndomänmodell, hålls ren, enkel och begriplig
  • revision-model.cds– lägger till ytterligare fält som krävs för granskning i en fil
  • auth-model.cds– lägger till kommentarer för auktorisering.

Primära nycklar

Liksom tabeller och CDS i SAP ABAP underhåller vi primärnycklar för entitet med nyckelord nyckel.

En primärnyckel kan återanvändas över hela modellen genom att använda metoden för vanliga definitioner.

Vi kan skapa en common.cds-modell där alla vanliga definitioner kan lagras.

// vanliga definitioner

enhet StandardEntity { nyckel-ID: UUID; } Nu kan dessa vanliga definitioner återanvändas enligt nedan: med { StandardEntity } från './common'; enhet Anställd: StandardEntity { namn: String; ... } Entity Manager : StandardEntity { name : String; ... }

 

Den gemensamma filen är redan skapad som standard med en fördefinierad enhet som heter cuid.

Mappning av UUID till OData

CDS mappar UUID till Edm.Guid, som standard, i alla OData-modeller. OData-standarden sätter dock upp restriktiva regler för Edm.Guid-värden – till exempel är endast avstavade strängar tillåtna – som kan komma i konflikt med befintlig data. Därför tillåter vi att standardmappningen åsidosätts enligt följande:

entity Books {

nyckel-ID: UUID @odata.Typ:'Edm.String';

.

}

Om det behövs kan du också lägga till anteckningen @odata.MaxLength för att åsidosätta motsvarande egenskap också.

Förening

Det används för att definiera förhållandet mellan två enheter. Liksom ABAP CDS använder vi också här ordet Förening. Här är nyckelordet många indikerar a 0..* kardinalitet. Restriktionerna för kardinalitet kan läggas till som en begränsning (där villkor) – till exempel genom att använda inte null.

kompositioner

Till skillnad från Association där vi associerar ett enhetsfält med objekten för en hel enhet, hänvisar sammansättningarna bara till ett specifikt område för en annan enhet. Den har extra fördel av självhanterade djupoperationer (Infoga/Uppdatera) och kaskadradering (Radering av multiberoende tabeller).

// Definiera order med inneslutna OrderItemsentity Orders { nyckel-ID: UUID; Artiklar : Sammansättning av många Order_Items på Items.parent=$self;}entity Order_Items { // ska endast nås via beställningar  nyckelförälder: Association to Orders; nyckelbok : Association to Books; kvantitet: heltal;}

Bästa praxis

  1. Lägg inte till tekniska detaljer i modeller, vi använder aspekterför det
  2. Använda korta namn och enkla platta modeller
  3. Övernormalisera inte enheterna i modeller
  4. Använd lokala heltalssekvenser om du verkligen hanterar höga belastningar och volymer. Föredrar annars UUID

Hittills har vi lärt oss: Skapande av modell och aspekter ovanpå det.

Domänmodellering i SAP CAP

Lämna en kommentar

Den här sidan använder Akismet för att minska spam. Läs om hur din kommentardata behandlas.