AWS DynamoDB MCP Server

ทางการ

เซิร์ฟเวอร์ MCP ประสบการณ์นักพัฒนาอย่างเป็นทางการสำหรับ Amazon DynamoDB เซิร์ฟเวอร์นี้ให้คำแนะนำการออกแบบจากผู้เชี่ยวชาญ DynamoDB และความช่วยเหลือในการสร้างแบบจำลองข้อมูล

GitHub

9.4k

เอกสาร

AWS DynamoDB MCP Server

เซิร์ฟเวอร์ MCP อย่างเป็นทางการเพื่อประสบการณ์นักพัฒนาสำหรับ Amazon DynamoDB เซิร์ฟเวอร์นี้ให้คำแนะนำการออกแบบจากผู้เชี่ยวชาญ DynamoDB และความช่วยเหลือด้านการสร้างแบบจำลองข้อมูล

[!IMPORTANT] Generative AI สามารถทำผิดพลาดได้ คุณควรพิจารณาตรวจสอบผลลัพธ์ทั้งหมดที่สร้างโดยโมเดล AI และผู้ช่วยเขียนโค้ดแบบ agentic ที่คุณเลือก ดู นโยบาย AI ที่มีความรับผิดชอบของ AWS

เครื่องมือที่พร้อมใช้งาน

เซิร์ฟเวอร์ DynamoDB MCP มีเครื่องมือแปดอย่างสำหรับการสร้างแบบจำลองข้อมูล การตรวจสอบความถูกต้อง การวิเคราะห์ต้นทุน และการสร้างโค้ด:

dynamodb_data_modeling - ดึงข้อมูลพร้อมท์ผู้เชี่ยวชาญการสร้างแบบจำลองข้อมูล DynamoDB ฉบับสมบูรณ์ พร้อมรูปแบบการออกแบบระดับองค์กร กลยุทธ์การปรับต้นทุนให้เหมาะสม และปรัชญาการออกแบบหลายตาราง นำทางผ่านการรวบรวมข้อกำหนด การวิเคราะห์รูปแบบการเข้าถึง และการออกแบบสคีมา

ตัวอย่างการเรียกใช้: "ออกแบบแบบจำลองข้อมูลสำหรับแอปพลิเคชันอีคอมเมิร์ซของฉันโดยใช้เซิร์ฟเวอร์ MCP การสร้างแบบจำลองข้อมูล DynamoDB"
dynamodb_data_model_validation - ตรวจสอบความถูกต้องของแบบจำลองข้อมูล DynamoDB ของคุณโดยโหลด dynamodb_data_model.json ตั้งค่า DynamoDB Local สร้างตารางด้วยข้อมูลทดสอบ และดำเนินการรูปแบบการเข้าถึงที่กำหนดไว้ทั้งหมด บันทึกผลการตรวจสอบโดยละเอียดไปยัง dynamodb_model_validation.json

ตัวอย่างการเรียกใช้: "ตรวจสอบความถูกต้องของแบบจำลองข้อมูล DynamoDB ของฉัน"
source_db_analyzer - วิเคราะห์ฐานข้อมูลที่มีอยู่ (MySQL, PostgreSQL, SQL Server, Oracle) เพื่อแยกโครงสร้างสคีมา รูปแบบการเข้าถึง และสร้างไฟล์การวิเคราะห์ที่มีการประทับเวลาสำหรับใช้กับ dynamodb_data_modeling รองรับทั้งการเข้าถึงผ่าน RDS Data API และการเข้าถึงผ่านการเชื่อมต่อสำหรับ MySQL

ตัวอย่างการเรียกใช้: "วิเคราะห์ฐานข้อมูล MySQL ของฉันและช่วยฉันออกแบบแบบจำลองข้อมูล DynamoDB"
generate_resources - สร้างทรัพยากรต่างๆ จากไฟล์ JSON แบบจำลองข้อมูล DynamoDB (dynamodb_data_model.json) ปัจจุบันรองรับเฉพาะประเภททรัพยากร cdk การส่ง cdk เป็นพารามิเตอร์ resource_type จะสร้างแอป CDK เพื่อปรับใช้ตาราง DynamoDB แอป CDK อ่าน dynamodb_data_model.json เพื่อสร้างตารางด้วยการกำหนดค่าที่เหมาะสม

ตัวอย่างการเรียกใช้: "สร้างทรัพยากรเพื่อปรับใช้แบบจำลองข้อมูล DynamoDB ของฉันโดยใช้ CDK"
dynamodb_data_model_schema_converter - แปลงแบบจำลองข้อมูลของคุณ (dynamodb_data_model.md) เป็นไฟล์ schema.json ที่มีโครงสร้างซึ่งแสดงตาราง ดัชนี เอนทิตี ฟิลด์ และรูปแบบการเข้าถึงของ DynamoDB รูปแบบที่เครื่องอ่านได้นี้ใช้สำหรับการสร้างโค้ดและสามารถขยายเพื่อวัตถุประสงค์อื่น เช่น การสร้างเอกสารหรือการจัดเตรียมโครงสร้างพื้นฐาน ตรวจสอบความถูกต้องของสคีมาโดยอัตโนมัติสูงสุด 8 รอบเพื่อให้แน่ใจว่าถูกต้อง

ตัวอย่างการเรียกใช้: "แปลงแบบจำลองข้อมูลของฉันเป็น schema.json สำหรับการสร้างโค้ด"
dynamodb_data_model_schema_validator - ตรวจสอบความถูกต้องของไฟล์ schema.json เพื่อความเข้ากันได้ในการสร้างโค้ด ตรวจสอบประเภทฟิลด์ การดำเนินการ การแมป GSI รหัสรูปแบบ และให้ข้อความแสดงข้อผิดพลาดโดยละเอียดพร้อมคำแนะนำในการแก้ไข ทำให้แน่ใจว่าสคีมาของคุณพร้อมสำหรับเครื่องมือ generate_data_access_layer

ตัวอย่างการเรียกใช้: "ตรวจสอบความถูกต้องของไฟล์ schema.json ของฉันที่ /path/to/schema.json"
generate_data_access_layer - สร้างโค้ด Python ที่ปลอดภัยต่อประเภทจาก schema.json รวมถึงคลาสเอนทิตีที่มีการตรวจสอบความถูกต้องของฟิลด์ คลาส repository ที่มีการดำเนินการ CRUD รูปแบบการเข้าถึงที่นำไปใช้อย่างสมบูรณ์ และตัวอย่างการใช้งานที่เป็นทางเลือก โค้ดที่สร้างขึ้นใช้ Pydantic สำหรับการตรวจสอบความถูกต้องและ boto3 สำหรับการดำเนินการ DynamoDB

ตัวอย่างการเรียกใช้: "สร้างโค้ด Python จาก schema.json ของฉัน"
compute_performances_and_costs - คำนวณหน่วยความจุ DynamoDB (RCU/WCU) และค่าใช้จ่ายรายเดือนจากรูปแบบการเข้าถึง วิเคราะห์การดำเนินการ DynamoDB ทั้งหมด (GetItem, Query, Scan, PutItem, UpdateItem, DeleteItem, BatchGetItem, BatchWriteItem, TransactGetItems, TransactWriteItems) ติดตามการเขียนเพิ่มเติมของ GSI และคำนวณค่าใช้จ่ายในการจัดเก็บ ผนวกรายงานค่าใช้จ่ายที่ครอบคลุมไปยัง dynamodb_data_model.md

ตัวอย่างการเรียกใช้: "คำนวณค่าใช้จ่ายและประสิทธิภาพสำหรับแบบจำลองข้อมูล DynamoDB ของฉัน"

ข้อกำหนดเบื้องต้น

ติดตั้ง uv จาก Astral หรือ GitHub README
ติดตั้ง Python โดยใช้ uv python install 3.10
ตั้งค่าข้อมูลประจำตัว AWS พร้อมการเข้าถึงบริการ AWS

การติดตั้ง

Kiro	Cursor	VS Code

หมายเหตุ: ปุ่มติดตั้งด้านบนกำหนดค่า AWS_REGION เป็น us-west-2 ตามค่าเริ่มต้น อัปเดตค่านี้ในการกำหนดค่า MCP ของคุณหลังการติดตั้งหากคุณต้องการภูมิภาคอื่น

เพิ่มเซิร์ฟเวอร์ MCP ไปยังไฟล์การกำหนดค่าของคุณ (สำหรับ Kiro เพิ่มไปยัง .kiro/settings/mcp.json - ดู เส้นทางการกำหนดค่า):

{
  "mcpServers": {
    "awslabs-dynamodb-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.dynamodb-mcp-server@latest"],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

การติดตั้งบน Windows

สำหรับผู้ใช้ Windows รูปแบบการกำหนดค่าเซิร์ฟเวอร์ MCP จะแตกต่างกันเล็กน้อย:

{
  "mcpServers": {
    "awslabs-dynamodb-mcp-server": {
      "disabled": false,
      "timeout": 60,
      "type": "stdio",
      "command": "uv",
      "args": [
        "tool",
        "run",
        "--from",
        "awslabs.dynamodb-mcp-server@latest",
        "awslabs.dynamodb-mcp-server.exe"
      ],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      }
    }
  }
}

การติดตั้ง Docker

หลังจาก docker build -t awslabs/dynamodb-mcp-server . สำเร็จ:

{
  "mcpServers": {
    "awslabs-dynamodb-mcp-server": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "--interactive",
        "--env",
        "FASTMCP_LOG_LEVEL=ERROR",
        "awslabs/dynamodb-mcp-server:latest"
      ],
      "env": {},
      "disabled": false,
      "autoApprove": []
    }
  }
}

การสร้างแบบจำลองข้อมูล

การสร้างแบบจำลองข้อมูลด้วยภาษาธรรมชาติ

ใช้เครื่องมือ dynamodb_data_modeling เพื่อออกแบบแบบจำลองข้อมูล DynamoDB ผ่านการสนทนาด้วยภาษาธรรมชาติกับเอเจนต์ AI ของคุณ เพียงถามว่า: "ใช้ DynamoDB MCP ของฉันเพื่อช่วยฉันออกแบบแบบจำลองข้อมูล DynamoDB"

เครื่องมือนี้มีเวิร์กโฟลว์ที่มีโครงสร้างซึ่งแปลข้อกำหนดของแอปพลิเคชันเป็นแบบจำลองข้อมูล DynamoDB:

ขั้นตอนการรวบรวมข้อกำหนด:

จับรูปแบบการเข้าถึงผ่านการสนทนาด้วยภาษาธรรมชาติ
จัดทำเอกสารเอนทิตี ความสัมพันธ์ และรูปแบบการอ่าน/เขียน
บันทึกคำขอต่อวินาที (RPS) โดยประมาณสำหรับแต่ละรูปแบบ
สร้างไฟล์ dynamodb_requirements.md ที่อัปเดตแบบเรียลไทม์
ระบุรูปแบบที่เหมาะกับบริการ AWS อื่นๆ มากกว่า (OpenSearch สำหรับการค้นหาข้อความ, Redshift สำหรับการวิเคราะห์)
ทำเครื่องหมายข้อควรพิจารณาในการออกแบบพิเศษ (เช่น รูปแบบ fan-out ขนาดใหญ่ที่ต้องการ DynamoDB Streams และ Lambda)

ขั้นตอนการออกแบบ:

สร้างการออกแบบตารางและดัชนีที่เหมาะสมที่สุด
สร้าง dynamodb_data_model.md พร้อมเหตุผลการออกแบบโดยละเอียด
ให้ค่าใช้จ่ายรายเดือนโดยประมาณ
จัดทำเอกสารว่าแต่ละรูปแบบการเข้าถึงได้รับการสนับสนุนอย่างไร
รวมคำแนะนำการปรับให้เหมาะสมสำหรับขนาดและประสิทธิภาพ

เครื่องมือนี้ได้รับการสนับสนุนโดยบริบทที่ออกแบบโดยผู้เชี่ยวชาญซึ่งช่วยให้โมเดลการให้เหตุผลนำทางคุณผ่านเทคนิคการสร้างแบบจำลองขั้นสูง ผลลัพธ์ที่ดีที่สุดจะได้รับจากโมเดลที่มีความสามารถในการให้เหตุผล เช่น Anthropic Claude 4/4.5 Sonnet, OpenAI o3 และ Google Gemini 2.5

การตรวจสอบความถูกต้องของแบบจำลองข้อมูล

ข้อกำหนดเบื้องต้นสำหรับการตรวจสอบความถูกต้องของแบบจำลองข้อมูล: ในการใช้เครื่องมือตรวจสอบความถูกต้องของแบบจำลองข้อมูล คุณต้องมีอย่างใดอย่างหนึ่งต่อไปนี้:

รันไทม์คอนเทนเนอร์: Docker, Podman, Finch หรือ nerdctl พร้อม daemon ที่ทำงานอยู่
รันไทม์ Java: Java JRE เวอร์ชัน 17 หรือใหม่กว่า (ตั้งค่า JAVA_HOME หรือตรวจสอบให้แน่ใจว่า java อยู่ใน PATH ของระบบของคุณ)

หลังจากเสร็จสิ้นการออกแบบแบบจำลองข้อมูลของคุณ ใช้เครื่องมือ dynamodb_data_model_validation เพื่อทดสอบแบบจำลองข้อมูลของคุณกับ DynamoDB Local โดยอัตโนมัติ เครื่องมือตรวจสอบความถูกต้องปิดวงจรระหว่างการสร้างและการดำเนินการโดยสร้างวงจรการตรวจสอบความถูกต้องแบบวนซ้ำ

วิธีการทำงาน:

เครื่องมือนี้ทำให้กระบวนการตรวจสอบความถูกต้องด้วยตนเองแบบดั้งเดิมเป็นไปโดยอัตโนมัติ:

การตั้งค่า: เริ่มสภาพแวดล้อม DynamoDB Local (Docker/Podman/Finch/nerdctl หรือทางเลือก Java)
สร้างข้อกำหนดการทดสอบ: สร้าง dynamodb_data_model.json ที่แสดงรายการตาราง ข้อมูลตัวอย่าง และรูปแบบการเข้าถึงที่จะทดสอบ
ปรับใช้สคีมา: สร้างตาราง ดัชนี และแทรกข้อมูลตัวอย่างในเครื่อง
ดำเนินการทดสอบ: รันการดำเนินการอ่านและเขียนทั้งหมดที่กำหนดไว้ในรูปแบบการเข้าถึงของคุณ
ตรวจสอบผลลัพธ์: ตรวจสอบว่าแต่ละรูปแบบการเข้าถึงทำงานอย่างถูกต้องและมีประสิทธิภาพ
การปรับแต่งแบบวนซ้ำ: หากการตรวจสอบความถูกต้องล้มเหลว (เช่น การสืบค้นส่งคืนผลลัพธ์ที่ไม่สมบูรณ์เนื่องจากคีย์พาร์ติชันไม่ตรงกัน) เครื่องมือจะบันทึกปัญหา และสร้างสคีมาที่ได้รับผลกระทบใหม่และรันการทดสอบอีกครั้งจนกว่ารูปแบบทั้งหมดจะผ่าน

ผลลัพธ์การตรวจสอบความถูกต้อง:

dynamodb_model_validation.json: ผลการตรวจสอบความถูกต้องโดยละเอียดพร้อมการตอบสนองของรูปแบบ
validation_result.md: สรุปกระบวนการตรวจสอบความถูกต้องพร้อมสถานะผ่าน/ไม่ผ่านสำหรับแต่ละรูปแบบการเข้าถึง
ระบุปัญหาเช่นโครงสร้างคีย์ที่ไม่ถูกต้อง ดัชนีที่ขาดหายไป หรือรูปแบบการสืบค้นที่ไม่มีประสิทธิภาพ

การวิเคราะห์ฐานข้อมูลต้นทาง

เครื่องมือ source_db_analyzer แยกสคีมาและรูปแบบการเข้าถึงจากฐานข้อมูลที่มีอยู่ของคุณเพื่อช่วยออกแบบแบบจำลอง DynamoDB ของคุณ สิ่งนี้มีประโยชน์เมื่อย้ายจากฐานข้อมูลเชิงสัมพันธ์

เครื่องมือนี้รองรับวิธีการเชื่อมต่อสองวิธีสำหรับ MySQL:

การเข้าถึงผ่าน RDS Data API: การเชื่อมต่อแบบไร้เซิร์ฟเวอร์โดยใช้ cluster ARN
การเข้าถึงผ่านการเชื่อมต่อ: การเชื่อมต่อแบบดั้งเดิมโดยใช้ชื่อโฮสต์/พอร์ต

ฐานข้อมูลที่รองรับ:

MySQL / Aurora MySQL
PostgreSQL
SQL Server
Oracle

โหมดการดำเนินการ:

โหมดบริการตนเอง: สร้างคำสั่ง SQL รันด้วยตัวเอง ให้ผลลัพธ์ (MySQL, PostgreSQL, SQL Server, Oracle)
โหมดจัดการ: การเชื่อมต่อโดยตรงผ่าน AWS RDS Data API (MySQL เท่านั้น)

เราแนะนำให้รันเครื่องมือนี้กับอินสแตนซ์ฐานข้อมูลที่ไม่ใช่โปรดักชัน

โหมดบริการตนเอง (MySQL, PostgreSQL, SQL Server, Oracle)

โหมดบริการตนเองช่วยให้คุณวิเคราะห์ฐานข้อมูลใดๆ โดยไม่ต้องมีการเชื่อมต่อ AWS:

สร้างคำสั่ง: เครื่องมือเขียนคำสั่ง SQL (ตามฐานข้อมูลที่เลือก) ไปยังไฟล์
รันคำสั่ง: คุณดำเนินการคำสั่งกับฐานข้อมูลของคุณ
ให้ผลลัพธ์: เครื่องมือแยกวิเคราะห์ผลลัพธ์และสร้างการวิเคราะห์

โหมดจัดการ (MySQL เท่านั้น)

โหมดจัดการช่วยให้คุณเชื่อมต่อเครื่องมือกับ AWS RDS Data API เพื่อวิเคราะห์ฐานข้อมูล MySQL/Aurora ที่มีอยู่เพื่อแยกสคีมาและรูปแบบการเข้าถึงสำหรับการสร้างแบบจำลอง DynamoDB

ข้อกำหนดเบื้องต้นสำหรับการรวม MySQL (โหมดจัดการ)

สำหรับการเข้าถึงผ่าน RDS Data API:

คลัสเตอร์ MySQL ที่เปิดใช้งาน RDS Data API
ข้อมูลประจำตัวฐานข้อมูลที่เก็บไว้ใน AWS Secrets Manager
ข้อมูลประจำตัว AWS พร้อมสิทธิ์ในการเข้าถึง RDS Data API และ Secrets Manager

สำหรับการเข้าถึงผ่านการเชื่อมต่อ:

เซิร์ฟเวอร์ MySQL ที่สามารถเข้าถึงได้จากสภาพแวดล้อมของคุณ
ข้อมูลประจำตัวฐานข้อมูลที่เก็บไว้ใน AWS Secrets Manager
ความลับของ Secrets Manager ต้อง มีฟิลด์ host ที่ตรงกับชื่อโฮสต์ฐานข้อมูลของคุณ (นอกเหนือจาก username และ password) สิ่งนี้ทำให้แน่ใจว่าข้อมูลประจำตัวถูกใช้กับโฮสต์ฐานข้อมูลที่ตั้งใจไว้เท่านั้น ความลับที่จัดการโดย RDS จะรวมฟิลด์นี้โดยอัตโนมัติ หากคุณสร้างความลับด้วยตนเอง ตรวจสอบให้แน่ใจว่าเป็นไปตาม โครงสร้างมาตรฐาน:
```
aws secretsmanager create-secret \
    --name "my-db-secret" \
    --secret-string '{
        "engine": "mysql",
        "host": "my-db.cluster-xxx.us-east-1.rds.amazonaws.com",
        "username": "<username>",
        "password": "<password>",
        "dbname": "<database name>",
        "port": 3306
    }'
```
ข้อมูลประจำตัว AWS พร้อมสิทธิ์ในการเข้าถึง Secrets Manager

สำหรับวิธีการเชื่อมต่อทั้งสอง: 4. เปิดใช้งาน Performance Schema สำหรับการวิเคราะห์รูปแบบการเข้าถึง (เป็นทางเลือกแต่แนะนำ):

ตั้งค่าพารามิเตอร์ performance_schema เป็น 1 ในกลุ่มพารามิเตอร์ DB ของคุณ
รีบูตอินสแตนซ์ DB หลังจากการเปลี่ยนแปลง
ตรวจสอบด้วย: SHOW GLOBAL VARIABLES LIKE '%performance_schema'
พิจารณาปรับแต่ง:
- performance_schema_digests_size - จำนวนแถวสูงสุดใน events_statements_summary_by_digest
- performance_schema_max_digest_length - ความยาวไบต์สูงสุดต่อไดเจสต์คำสั่ง (ค่าเริ่มต้น: 1024)
หากไม่มี Performance Schema การวิเคราะห์จะอิงตาม information schema เท่านั้น

ตัวแปรสภาพแวดล้อม MySQL

เพิ่มตัวแปรสภาพแวดล้อมเหล่านี้เพื่อเปิดใช้งานการรวม MySQL:

สำหรับการเข้าถึงผ่าน RDS Data API:

MYSQL_CLUSTER_ARN: MySQL cluster ARN
MYSQL_SECRET_ARN: ARN ของความลับที่มีข้อมูลประจำตัวฐานข้อมูล
MYSQL_DATABASE: ชื่อฐานข้อมูลที่จะวิเคราะห์
AWS_REGION: ภูมิภาค AWS ของคลัสเตอร์

สำหรับการเข้าถึงผ่านการเชื่อมต่อ:

MYSQL_HOSTNAME: ชื่อโฮสต์หรือจุดสิ้นสุดของเซิร์ฟเวอร์ MySQL
MYSQL_PORT: พอร์ตเซิร์ฟเวอร์ MySQL (เป็นทางเลือก ค่าเริ่มต้น: 3306)
MYSQL_SECRET_ARN: ARN ของความลับที่มีข้อมูลประจำตัวฐานข้อมูล
MYSQL_DATABASE: ชื่อฐานข้อมูลที่จะวิเคราะห์
AWS_REGION: ภูมิภาค AWS ที่ Secrets Manager ตั้งอยู่

ตัวเลือกทั่วไป:

MYSQL_MAX_QUERY_RESULTS: จำนวนแถวสูงสุดในไฟล์ผลลัพธ์การวิเคราะห์ (เป็นทางเลือก ค่าเริ่มต้น: 500)

หมายเหตุ: พารามิเตอร์เครื่องมือที่ระบุอย่างชัดเจนมีความสำคัญเหนือกว่าตัวแปรสภาพแวดล้อม ควรระบุวิธีการเชื่อมต่อเพียงวิธีเดียว (cluster ARN หรือชื่อโฮสต์)

การกำหนดค่า MCP กับ MySQL

สำหรับการเข้าถึงผ่าน RDS Data API:

{
  "mcpServers": {
    "awslabs-dynamodb-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.dynamodb-mcp-server@latest"],
      "env": {
        "AWS_PROFILE": "default",
        "AWS_REGION": "us-west-2",
        "FASTMCP_LOG_LEVEL": "ERROR",
        "MYSQL_CLUSTER_ARN": "arn:aws:rds:$REGION:$ACCOUNT_ID:cluster:$CLUSTER_NAME",
        "MYSQL_SECRET_ARN": "arn:aws:secretsmanager:$REGION:$ACCOUNT_ID:secret:$SECRET_NAME",
        "MYSQL_DATABASE": "<DATABASE_NAME>",
        "MYSQL_MAX_QUERY_RESULTS": "500"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

สำหรับการเข้าถึงผ่านการเชื่อมต่อ:

{
  "mcpServers": {
    "awslabs.dynamodb-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.dynamodb-mcp-server@latest"],
      "env": {
        "AWS_PROFILE": "default",
        "AWS_REGION": "us-west-2",
        "FASTMCP_LOG_LEVEL": "ERROR",
        "MYSQL_HOSTNAME": "<MYSQL_HOST>",
        "MYSQL_PORT": "3306",
        "MYSQL_SECRET_ARN": "arn:aws:secretsmanager:$REGION:$ACCOUNT_ID:secret:$SECRET_NAME",
        "MYSQL_DATABASE": "<DATABASE_NAME>",
        "MYSQL_MAX_QUERY_RESULTS": "500"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

การใช้การวิเคราะห์ฐานข้อมูลต้นทาง

รัน source_db_analyzer กับฐานข้อมูลของคุณ (โหมด Self-service หรือ Managed)
ตรวจสอบโฟลเดอร์การวิเคราะห์ที่มีการประทับเวลา (database_analysis_YYYYMMDD_HHMMSS)
อ่านไฟล์ manifest.md ก่อน - ไฟล์นี้แสดงรายการไฟล์วิเคราะห์และสถิติทั้งหมด
อ่านไฟล์วิเคราะห์ทั้งหมดเพื่อทำความเข้าใจโครงสร้างสคีมาและรูปแบบการเข้าถึง
ใช้การวิเคราะห์ร่วมกับ dynamodb_data_modeling เพื่อออกแบบสคีมา DynamoDB ของคุณ

เครื่องมือนี้สร้างไฟล์ Markdown ที่ประกอบด้วย:

โครงสร้างสคีมา (ตาราง, คอลัมน์, ดัชนี, foreign keys)
รูปแบบการเข้าถึงจาก Performance Schema (รูปแบบคิวรี, RPS, ความถี่)
การวิเคราะห์ที่มีการประทับเวลาสำหรับการติดตามการเปลี่ยนแปลงเมื่อเวลาผ่านไป

การแปลงสคีมาและการสร้างโค้ด

หลังจากออกแบบโมเดลข้อมูล DynamoDB ของคุณแล้ว คุณสามารถแปลงเป็นสคีมาแบบมีโครงสร้างและสร้างโค้ด Python อ้างอิงได้ เมื่อใช้เครื่องมือ MCP ผ่าน LLM ขั้นตอนการทำงานทั้งหมดนี้จะเกิดขึ้นโดยอัตโนมัติ - LLM จะแนะนำคุณผ่านการแปลงสคีมา การตรวจสอบ และการสร้างโค้ดในการสนทนาเดียว โดยไม่ต้องเรียกใช้เครื่องมือด้วยตนเอง

สำหรับการใช้งานแบบสแตนด์อโลน คุณยังสามารถเรียกใช้เครื่องมือเหล่านี้โดยตรงผ่าน CLI หรือแก้ไขไฟล์ schema.json ด้วยตนเองและสร้างโค้ดใหม่ตามต้องการ

หมายเหตุ: การตรวจสอบโมเดลข้อมูล (dynamodb_data_model_validation) เป็นทางเลือกสำหรับการสร้างโค้ด อย่างไรก็ตาม หากคุณวางแผนที่จะทดสอบโค้ดที่สร้างขึ้นด้วย usage_examples.py กับ DynamoDB Local แนะนำให้รันการตรวจสอบก่อน เนื่องจากจะตั้งค่าตารางและข้อมูลทดสอบใน DynamoDB Local โดยอัตโนมัติ

การแปลงโมเดลข้อมูลเป็นสคีมา

เครื่องมือ dynamodb_data_model_schema_converter แปลงโมเดลข้อมูลที่มนุษย์อ่านได้ (dynamodb_data_model.md) เป็นสคีมา JSON แบบมีโครงสร้างที่แสดงตาราง DynamoDB, ดัชนี, เอนทิตี และรูปแบบการเข้าถึงของคุณ รูปแบบที่เครื่องอ่านได้นี้ช่วยให้สามารถสร้างโค้ดและสามารถขยายสำหรับเอกสารหรือการจัดเตรียมโครงสร้างพื้นฐาน

เครื่องมือจะตรวจสอบสคีมาที่สร้างขึ้นโดยอัตโนมัติ โดยให้ข้อความแสดงข้อผิดพลาดโดยละเอียดและคำแนะนำการแก้ไขหากการตรวจสอบล้มเหลว ผลลัพธ์จะถูกบันทึกไปยังโฟลเดอร์ที่มีการประทับเวลาเพื่อการแยกส่วน

โครงสร้างสคีมา:

schema.json ที่สร้างขึ้นเป็นการแสดงแบบมีโครงสร้างที่ประกอบด้วย:

Tables: คำจำกัดความตาราง DynamoDB หนึ่งรายการขึ้นไปพร้อม partition/sort keys
GSI Definitions: การกำหนดค่า Global Secondary Index (ทางเลือก)
Entities: โมเดลโดเมน (User, Order, Product, ฯลฯ) พร้อมฟิลด์ที่มีชนิดข้อมูล
Field Types: string, integer, decimal, boolean, array, object, uuid
Access Patterns: การดำเนินการ Query/Scan/GetItem พร้อมคำจำกัดความพารามิเตอร์และเทมเพลตคีย์
Key Templates: รูปแบบสำหรับการสร้าง partition และ sort keys (เช่น USER#{user_id})

รูปแบบที่มีโครงสร้างนี้ทำหน้าที่เป็นอินพุตสำหรับเครื่องมือสร้างโค้ด

การตรวจสอบไฟล์สคีมา

เครื่องมือ dynamodb_data_model_schema_validator ตรวจสอบไฟล์ schema.json ของคุณเพื่อให้แน่ใจว่ามีรูปแบบที่ถูกต้องสำหรับการสร้างโค้ด

การตรวจสอบ:

มีส่วนที่จำเป็น (table_config, entities)
มีฟิลด์ที่จำเป็นทั้งหมด
ชนิดฟิลด์ถูกต้อง (string, integer, decimal, boolean, array, object, uuid)
ค่า enum ถูกต้อง (ชนิดการดำเนินการ, ชนิดการส่งคืน)
Pattern IDs ไม่ซ้ำกันในทุกเอนทิตี
ชื่อ GSI ตรงกันระหว่าง gsi_list และ gsi_mappings
ฟิลด์ที่อ้างอิงในเทมเพลตมีอยู่ในฟิลด์เอนทิตี
เงื่อนไขช่วงถูกต้องด้วยจำนวนพารามิเตอร์ที่ถูกต้อง
รูปแบบการเข้าถึงมีการดำเนินการและชนิดการส่งคืนที่ถูกต้อง

ความปลอดภัย:

ไฟล์สคีมาต้องอยู่ภายในไดเรกทอรีการทำงานปัจจุบันหรือไดเรกทอรีย่อย ความพยายามในการเข้าถึงเส้นทางนอกเหนือจะถูกบล็อกเพื่อความปลอดภัย

ตัวอย่างผลลัพธ์การตรวจสอบ:

สำเร็จ:

✅ Schema validation passed!

ข้อผิดพลาดพร้อมคำแนะนำ:

❌ Schema validation failed:
  • entities.User.fields[0].type: Invalid type value 'strng'
    💡 Did you mean 'string'? Valid options: string, integer, decimal, boolean, array, object, uuid

การสร้าง Data Access Layer

เครื่องมือ generate_data_access_layer สร้างโค้ด Python แบบ type-safe จากไฟล์ schema.json ที่ผ่านการตรวจสอบแล้ว

โค้ดที่สร้างขึ้น:

Entity Classes: โมเดล Pydantic พร้อมการตรวจสอบฟิลด์และความปลอดภัยของชนิดข้อมูล
Repository Classes: การดำเนินการ CRUD (create, read, update, delete) สำหรับแต่ละเอนทิตี
Access Patterns: การดำเนินการ query และ scan ที่นำไปใช้อย่างสมบูรณ์จากสคีมาของคุณ
Base Repository: ฟังก์ชันการทำงานที่ใช้ร่วมกันสำหรับ repository ทั้งหมด
Usage Examples: โค้ดตัวอย่างที่แสดงวิธีการใช้คลาสที่สร้างขึ้น (ทางเลือก)
Configuration: ruff.toml สำหรับคุณภาพโค้ดและการจัดรูปแบบ

ข้อกำหนดเบื้องต้นสำหรับการสร้างโค้ด:

โค้ด Python ที่สร้างขึ้นต้องการการพึ่งพารันไทม์เหล่านี้:

pydantic>=2.0 - สำหรับการตรวจสอบเอนทิตีและความปลอดภัยของชนิดข้อมูล
boto3>=1.38 - สำหรับการดำเนินการ DynamoDB

ติดตั้งในโปรเจกต์ของคุณ:

uv add pydantic boto3
# or
pip install pydantic boto3

การพึ่งพาการพัฒนาเพิ่มเติม:

สำหรับการ linting และการจัดรูปแบบโค้ดที่สร้างขึ้น:

ruff==0.15.8 - Python linter และ formatter (แนะนำ)

โครงสร้างไฟล์ที่สร้างขึ้น:

generated_dal/
├── entities.py              # Pydantic entity models
├── repositories.py          # Repository classes with CRUD operations
├── base_repository.py       # Base repository functionality
├── transaction_service.py   # Cross-table transaction methods (if schema includes cross_table_access_patterns)
├── access_pattern_mapping.json  # Pattern ID to method mapping
├── usage_examples.py        # Sample usage code (if enabled)
└── ruff.toml               # Linting configuration

การใช้โค้ดที่สร้างขึ้น:

โค้ดที่สร้างขึ้นมีคลาสเอนทิตีแบบ type-safe และเมธอด repository สำหรับรูปแบบการเข้าถึงทั้งหมดของคุณ:

from generated_dal.repositories import UserRepository
from generated_dal.entities import User

# Initialize repository
repo = UserRepository(table_name="MyTable")

# Create a new user
user = User(user_id="123", username="username", name="John Doe")
repo.create(user)

# Query by access pattern
users = repo.get_user_by_username(username="username")

# Update user
user.name = "Jane Doe"
repo.update(user)

สำหรับการ linting และการจัดรูปแบบโค้ดที่สร้างขึ้นด้วย ruff:

ruff check generated_dal/        # Check for issues
ruff check --fix generated_dal/  # Auto-fix issues
ruff format generated_dal/       # Format code