การสร้างแบบจำลองโดเมนใน SAP CAP

บทนำ

โมเดลโดเมนใน SAP CAP เป็นโมเดลที่อธิบายลักษณะคงที่ที่เกี่ยวข้องกับข้อมูลของโดเมนปัญหาในแง่ของโมเดลความสัมพันธ์เอนทิตี ในบทความนี้เราจะศึกษาการสร้างแบบจำลองโดเมนใน SAP CAP โดยละเอียด

การสร้างแบบจำลองโดเมน

พูดง่ายๆ ก็คือ CDS ใน SAP CAP จะสร้างโมเดลโดเมนในลักษณะที่กำหนดปัญหาทางธุรกิจในแง่ของคีย์ ฟิลด์ และคำอธิบายประกอบ โค้ดสำหรับสร้างโมเดลโดเมนเขียนใน CDS schema (db/schema.cds) โมเดลโดเมนเหล่านี้สามารถใช้ได้ในข้อกำหนดบริการ โมเดลความคงอยู่ ฐานข้อมูล หรือแม้แต่นำกลับมาใช้ใหม่ภายในโมเดลโดเมนอื่น

ตัวอย่างตัวอย่าง:

เนมสเปซ empInfo; โดยใช้ {Currency, ที่ได้รับการจัดการ} จาก '@sap/cds/common'; นิติบุคคล พนักงาน: จัดการ { รหัสคีย์: จำนวนเต็ม; ชื่อจริง: สตริงที่แปลเป็นภาษาท้องถิ่น (111); นามสกุล: สตริงที่แปลเป็นภาษาท้องถิ่น (1111); ผู้จัดการ: สมาคมกับผู้จัดการ; dateofJoining: จำนวนเต็ม; เงินเดือน: ทศนิยม (9,2); สกุลเงิน: สกุลเงิน; }

 

ในตัวอย่างนี้ เราได้สร้างไฟล์ schema.cds ที่เราได้สร้างเอนทิตีพนักงานซึ่งรวมถึงรายละเอียดพื้นฐานของพนักงาน

สคีมาทั้งหมดนี้ได้รับเนมสเปซเช่น empInfo

สคีมานี้ใช้ชนิดข้อมูลมาตรฐาน เช่น สกุลเงิน การใช้ชนิดข้อมูลมาตรฐานเช่นนี้ช่วยให้เราสามารถนำค่าที่กำหนดไว้ล่วงหน้าทั้งหมดมาช่วยในการที่เกี่ยวข้อง

เราใช้ CDS เพื่อสร้างแบบจำลอง ในซีดีนั้น เราใช้

  1. เอนทิตีที่แสดงถึงชุดของอ็อบเจ็กต์ที่ไม่ซ้ำกัน เช่น:
    1. ข้อมูลพื้นฐานของพนักงาน
    2. ข้อมูลการสื่อสารของพนักงาน
    3. ข้อมูลเงินเดือนพนักงาน
  2. สมาคมเพื่อกำหนดความสัมพันธ์
    1. ผู้จัดการเชื่อมโยงกับหน่วยงานอื่น ผู้จัดการซึ่งจะมีรายชื่อผู้จัดการทั้งหมด

อนุสัญญาการตั้งชื่อและข้อเสนอแนะ

  1. ชื่อของนิติบุคคลควรขึ้นต้นด้วยอักษรตัวใหญ่และควรเป็นข้อมูลที่มนุษย์สามารถอ่านได้และอธิบายตนเองได้ ตัวอย่างเช่น พนักงาน
  2. เริ่มองค์ประกอบด้วยอักษรตัวพิมพ์เล็ก – ตัวอย่างเช่น firstName
  3. ขอแนะนำให้ใช้เอนทิตีรูปพหูพจน์ เช่น Employee
  4. ขอแนะนำให้ใช้รูปแบบเอกพจน์ – ตัวอย่างเช่น Currency
  5. อย่าใช้บริบทซ้ำ เช่น Employee.name แทนที่จะเป็น Employee.EmployeeName
  6. ชอบชื่อที่มีคำเดียว เช่น เงินเดือนแทนเงินเดือนจำนวนเงิน
  7. ใช้ ID สำหรับคีย์หลักทางเทคนิค – ตัวอย่างเช่น ID สำหรับ ID พนักงาน
  8. คุณสามารถใช้เนมสเปซเพื่อทำให้เอนทิตีของคุณไม่ซ้ำกัน มันเหมือนกับแนวคิดไคลเอนต์ใน SAP ที่คุณสามารถมีสคีมาที่ซ้ำกัน (ไฟล์ cds) ด้วยเนมสเปซที่ไม่ซ้ำกันเพื่อสร้างความแตกต่าง เนมสเปซเป็นทางเลือก ใช้เนมสเปซหากแบบจำลองของคุณอาจถูกนำมาใช้ซ้ำในโปรเจ็กต์อื่น ในตอนท้าย สิ่งเหล่านี้เป็นเพียงคำนำหน้า ซึ่งจะนำไปใช้กับชื่อที่เกี่ยวข้องทั้งหมดในไฟล์โดยอัตโนมัติ - ตัวอย่างเช่น,

แล็ปท็อปเนมสเปซเอนทิตี Dell {}

..… เทียบเท่ากับ:

เอนทิตีแล็ปท็อป Dell {}

  1. คุณสามารถใช้บริบทสำหรับส่วนเนมสเปซที่ซ้อนกัน - ตัวอย่างเช่น,

แล็ปท็อปเนมสเปซเอนทิตี Dell {}           //> โน้ตบุ๊ก.Dellบริบท Apple { เอนทิตี MacBookPro {}       //> แล็ปท็อป Apple.MacBookPro     เอนทิตี MacBookAir {} }

 

หน่วยงาน

เอนทิตีเป็นเหมือนตารางที่มีคีย์หลัก เราสามารถดำเนินการ CRUD โดยใช้เอนทิตีเหล่านี้ ให้แบนราบที่สุด อย่าให้เกิน Normalize มัน อย่าใช้ประเภทที่ไม่สามารถนำกลับมาใช้ใหม่ได้ ส่วนนี้มีไว้สำหรับการสร้างแบบจำลองเท่านั้น ควรเพิ่มเฉพาะคำอธิบายประกอบที่เกี่ยวข้องกับแต่ละฟิลด์และไม่ควรเพิ่มรายละเอียดทางเทคนิค (ตรรกะ)

ประเภท

ประเภทเป็นเหมือนโดเมนใน SAP ABAP ซึ่งใช้เพื่อกำหนดประเภทขององค์ประกอบข้อมูล

ด้าน

ลักษณะเป็นส่วนขยายของแบบจำลองและส่วนใหญ่จะใช้เพื่อขยายคำจำกัดความและคำอธิบายประกอบที่มีอยู่ เมื่อกำหนดโมเดลแล้ว เราสามารถใช้ไฟล์ cds (Aspect) ที่แตกต่างกันเพื่อเพิ่มคำอธิบายประกอบไว้ด้านบนสำหรับงานเฉพาะ

ตัวอย่างเช่น-

  • แผ่นซีดี– โมเดลโดเมนหลักของคุณ รักษาความสะอาด เรียบง่าย และเข้าใจได้
  • audit-model.cds– เพิ่มฟิลด์เพิ่มเติมที่จำเป็นสำหรับการตรวจสอบในไฟล์
  • auth-model.cds- เพิ่มคำอธิบายประกอบสำหรับการอนุญาต

คีย์หลัก

เช่นเดียวกับตาราง & CDS ใน SAP ABAP เรารักษาคีย์หลักสำหรับเอนทิตีโดยใช้คีย์เวิร์ด กุญแจ

คีย์หลักสามารถนำมาใช้ซ้ำได้ทั่วทั้งโมเดลโดยใช้วิธีการของคำจำกัดความทั่วไป

เราสามารถสร้าง common.cds Model ซึ่งสามารถเก็บคำจำกัดความทั่วไปทั้งหมดได้

// คำจำกัดความทั่วไป

เอนทิตี StandardEntity { รหัสคีย์: UUID; } ตอนนี้คำจำกัดความทั่วไปเหล่านี้สามารถนำมาใช้ซ้ำได้ดังนี้: ใช้ { StandardEntity } จาก './common'; นิติบุคคล พนักงาน: StandardEntity { ชื่อ: สตริง; ... } ตัวจัดการเอนทิตี : StandardEntity { ชื่อ : สตริง; ... }

 

ไฟล์ทั่วไปถูกสร้างขึ้นโดยค่าเริ่มต้นแล้วโดยมีเอนทิตีที่กำหนดไว้ล่วงหน้าชื่อ cuid.

การแมป UUID กับ OData

CDS จะจับคู่ UUID กับ Edm.Guid ตามค่าเริ่มต้นในโมเดล OData ทั้งหมด อย่างไรก็ตาม มาตรฐาน OData กำหนดกฎเกณฑ์ที่จำกัดสำหรับค่า Edm.Guid ตัวอย่างเช่น อนุญาตให้ใช้เฉพาะสตริงที่มียัติภังค์เท่านั้น ซึ่งอาจขัดแย้งกับข้อมูลที่มีอยู่ ดังนั้นเราจึงอนุญาตให้แทนที่การแมปเริ่มต้นดังต่อไปนี้:

หนังสือนิติบุคคล {

รหัสคีย์ : UUID @odata.Type:'Edm.String';

...

}

หากจำเป็น คุณสามารถเพิ่มคำอธิบายประกอบ @odata.MaxLength เพื่อแทนที่คุณสมบัติที่เกี่ยวข้องได้เช่นกัน

สมาคม

ใช้เพื่อกำหนดความสัมพันธ์ระหว่างสองหน่วยงาน เช่นเดียวกับ ABAP CDS ที่นี่เราใช้คำว่า สมาคม. ที่นี่ คำหลัก หลาย ระบุว่า 0..* คาร์ดินัลลิตี้ คุณสามารถเพิ่มข้อจำกัดสำหรับจำนวนสมาชิกเป็นข้อจำกัดได้ (โดยที่เงื่อนไข) – ตัวอย่างเช่น การใช้ ไม่เป็นโมฆะ.

องค์ประกอบ

ต่างจากสมาคมที่เราเชื่อมโยงเขตข้อมูลของเอนทิตีกับออบเจ็กต์ของเอนทิตีทั้งหมด การเรียบเรียงเพียงแค่อ้างถึงฟิลด์เฉพาะของเอนทิตีอื่น มีข้อได้เปรียบพิเศษของการดำเนินการเชิงลึกที่จัดการด้วยตนเอง (แทรก/อัปเดต) และการลบแบบเรียงซ้อน (การลบตารางขึ้นอยู่กับหลายรายการ)

// กำหนดคำสั่งซื้อด้วย OrderItems ที่มีอยู่คำสั่งซื้อเอนทิตี { รหัสคีย์: UUID; รายการ : องค์ประกอบของ Order_Items หลายรายการใน Items.parent=$self;}entity Order_Items { // สามารถเข้าถึงได้ผ่านคำสั่งซื้อเท่านั้น  ผู้ปกครองหลัก : เชื่อมโยงกับคำสั่งซื้อ; หนังสือสำคัญ : สมาคมกับหนังสือ; ปริมาณ : จำนวนเต็ม;}

แนวทางปฏิบัติที่ดีที่สุด

  1. อย่าเพิ่มรายละเอียดทางเทคนิคในโมเดล เราใช้ ด้านสำหรับการที่
  2. ใช้ ชื่อสั้น และ  โมเดลแบนๆ
  3. ไม่เกิน Normalize เอนทิตีใน Models
  4. ใช้ลำดับจำนวนเต็มในเครื่องหากคุณจัดการกับโหลดและปริมาณมากจริงๆ มิฉะนั้น ชอบ UUIDs

จนถึงขณะนี้ สิ่งที่เราได้เรียนรู้: การสร้างแบบจำลองและลักษณะที่อยู่เหนือมัน

การสร้างแบบจำลองโดเมนใน SAP CAP

ทิ้งข้อความไว้

ไซต์นี้ใช้ Akismet เพื่อลดสแปม เรียนรู้วิธีการประมวลผลข้อมูลความคิดเห็นของคุณ.