Antaŭparolo – Ĉi tiu afiŝo estas parto de la SAP CAPM serio.
Enhavtabelo
Enkonduko
Domajna Modelo en SAP CAP estas modelo kiu priskribas la senmovajn, datenrilatajn aspektojn de problemdomajno laŭ ento-rilataj modeloj. En ĉi tiu artikolo ni detale studos la Domajnan Modeladon en SAP CAP.
Domajna Modeligado
En simplaj vortoj, KD en SAP CAP produktas domajnan modelon tiel, ke ĝi difinas la komercan problemon laŭ ŝlosiloj, kampoj kaj komentarioj. La kodo por generi domajnan modelon estas skribita en CDS-skemo (db/schema.cds). Ĉi tiuj domajnaj modeloj povas esti uzataj en Servaj Difinoj, Persistaj Modeloj, Datumbazoj aŭ eĉ reuzitaj ene de alia domajna modelo.
Ekzemplo:
Nomspaco empInfo; uzante {Currency, managed} de '@sap/cds/common'; ento Dungitoj: administrita { ŝlosila ID: Entjero; antaŭnomo: lokalizita Ŝnuro (111); familinomo: lokalizita Ŝnuro (1111); manaĝero: Asocio al Administrantoj; dato de kuniĝo: Entjero; salajro: Decimala (9,2); valuto: Monero; }
En ĉi tiu ekzemplo ni kreis dosieron schema.cds kie ni kreis enton Dungitoj kiu inkluzivas bazajn detalojn de Dungito
Ĉi tiu tuta skemo ricevis nomspacon t.e. empInfo
Ĉi tiu skemo uzas norman datumtipo t.e. Monero. Uzi la norman datumtipon tiel helpas nin alporti ĉiujn antaŭdifinitajn valorajn helpojn rilatajn al ĝi.
Ni uzas KDS por krei Modelon. En tiu KD, ni uzas
- Entoj por reprezenti aron de unikaj objektoj ekz:
- Bazaj Informoj pri Dungitoj
- Informoj pri Komunikado de Oficistoj
- Informoj pri Salajro de Dungitoj
- Asocioj por difini rilatojn
- Manaĝerasocio al alia ento Administranto kiu havos la tutan liston de Administrantoj
Nomada Konvencio & Rekomendoj
- La nomo de ento devas komenci per majuskla litero kaj ĝi estu homlegebla kaj memklarigebla - ekzemple, Dungitoj
- Komencu elementojn per minuskla litero - ekzemple antaŭnomo
- Oni rekomendas uzi pluralan formon de entoj - ekzemple, Dungitoj
- Oni rekomendas uzi singularan formon de tipoj - ekzemple Monero
- ne ripetu kuntekstojn – ekzemple Employees.name anstataŭ Employees.EmployeeName
- preferu unuvortajn nomojn – ekzemple salajro anstataŭ salajroKvanto
- uzu ID por teknikaj ĉefaj ŝlosiloj - ekzemple ID por dungita ID
- Vi povas uzi Nomspacon por fari viajn entojn unikajn. Ĝi estas kiel klienta koncepto en SAP kie vi povas havi duplikatajn skemojn (cds-dosieroj) kun unika Nomspaco por diferencigi ilin. Nomspacoj estas laŭvolaj, uzu nomspacojn se viaj modeloj povus esti reuzataj en aliaj projektoj. Fine de la tago ili estas nur prefiksoj, kiuj estas aŭtomate aplikataj al ĉiuj koncernaj nomoj en dosiero. - ekzemple,
nomspaco portebla; ento Dell {}
..… estas ekvivalenta al:
enta tekkomputilo.Dell {}
- Vi povas uzi kuntekstojn por nestitaj nomspacaj sekcioj. - ekzemple,
nomspaco portebla; ento Dell {} //> tekkomputilo.Dellkunteksto Apple { ento MacBookPro {} //> tekkomputilo.Apple.MacBookPro ento MacBookAir {} }
Entoj
Entoj estas kiel tabeloj kun primaraj ŝlosiloj. Ni povas fari CRUD-operacion uzante ĉi tiujn Entojn. Konservu ĝin kiel eble plej plata. Ne tro Normaligu ĝin. Ne uzu nereuzeblajn tipojn. Ĉi tiu sekcio estas nur por modeligado, nur komentario rilata al individuaj kampoj devus esti aldonita kaj neniuj teknikaj detaloj (logikoj) devus esti aldonitaj.
Tipoj
Tipoj estas kiel Domajno en SAP ABAP, ĝi kutimis difini la tajpitan de Datumaj elementoj.
Aspektoj
Aspektoj estas la etendaĵoj de la Modeloj kaj estas ĉefe uzataj por etendi la ekzistantajn difinojn kaj komentadojn. Post kiam modelo estas difinita, ni povas uzi malsamajn cd-dosierojn (Aspekto) por aldoni komentariojn al ili por specifa tasko.
Ekzemple-
- cds- via kerna domajna modelo, konservita pura, simpla kaj komprenebla
- audit-model.cds– aldonas pliajn kampojn necesajn por revizio en dosiero
- aŭth-model.cds– aldonas komentariojn por rajtigo.
Primaraj Ŝlosiloj
Kiel tabeloj kaj KD en SAP ABAP, ni konservas Ĉefŝlosilojn por Ento per ŝlosilvorto Ŝlosilo.
Primara ŝlosilo povas esti recikligita trans la modelo uzante la metodaron de oftaj difinoj.
Ni povas krei common.cds-Modelo kie ĉiuj komunaj difinoj povas esti stokitaj.
// komunaj difinoj
ento StandardEntity { ŝlosila ID : UUID; } Nun ĉi tiuj oftaj difinoj povas esti reuzitaj kiel sube: uzante { StandardEntity } de './common'; ento Dungito : StandardEntity { nomo : Ŝnuro; ... } ento Administranto : StandardEntity { nomo : Ŝnuro; ...}
La komuna dosiero jam estas kreita defaŭlte kun antaŭdifinita ento nomita cuid.
Mapado de UUID-oj al OData
CDS mapas UUID-ojn al Edm.Guid, defaŭlte, en ĉiuj OData-modeloj. Tamen, la OData normo prezentas restriktajn regulojn por Edm.Guid-valoroj - ekzemple, nur dividostrekitaj ĉenoj estas permesitaj - kiuj povas konflikti kun ekzistantaj datumoj. Tial, ni permesas la defaŭltan mapadon esti anstataŭita jene:
entaj Libroj {
ŝlosila ID: UUID @odata.Tajpu:'Edm.String';
...
}
Se necese, vi ankaŭ povas aldoni la komentarion @odata.MaxLength por superregi la respondan posedaĵon ankaŭ.
asocio
Ĝi estas uzata por difini rilaton inter du estaĵoj. Kiel ABAP CDS, ankaŭ ĉi tie ni uzas la vorton Asocio. Jen, la ŝlosilvorto multaj indikas a 0..* kardinaleco. La restriktoj por kardinaleco povas esti aldonitaj kiel limo (kie kondiĉo) - ekzemple, uzante ne nula.
Komponadoj
Male al Asocio, kie ni asocias kampon de ento kun la objektoj de tuta ento, la kunmetaĵoj nur rilatas al specifa kampo de alia ento. Ĝi havas ekstran avantaĝon de mem-administrataj profundaj operacioj (Enmeti/Ĝisdatigi) kaj kaskada forigo (Multdependa tabelforigo).
// Difinu Mendojn kun enhavitaj Mendojento Mendoj { ŝlosila ID : UUID; Eroj : Kunmetaĵo de multaj Order_Items sur Items.parent=$self;}entity Order_Items { // estos alirebla nur per Mendoj ŝlosila gepatro : Asocio al Ordoj; ŝlosila libro : Asocio al Libroj; kvanto : Entjero;}
Plej bonaj Praktikoj
- Ne aldonu teknikajn detalojn en Modeloj, ni uzas Aspektojpor ke
- uzo mallongaj nomoj kaj simplaj plataj modeloj
- Ne tro Normaligu la estaĵojn en Modeloj
- Uzu lokajn entjerajn sekvencojn se vi vere traktas altajn ŝarĝojn kaj volumojn. Alie, preferu UUIDojn
Ĝis nun kion ni lernis: Kreado de Modelo kaj Aspektoj sur ĝi.
0 Komentoj