تجاوز إلى المحتوى
تعلّم لعملك المرجع مقالات المحفوظات
العربية

playbook

حوّل ملفين فوضويين إلى dataset واحد جدير بالثقة

وحّد المفاتيح، واعمل join على الـ id الصحيح، وأبرِز كل صف لا يتطابق، وراجع النتيجة مقابل المدخلات — حتى يصير الملف المدموج شيئًا تستطيع فعلًا أن تبني عليه تقريرًا.

متوسّط ~40 دقيقة

متى تلجأ إلى هذا

لديك ملفان يُفترض أن يتلاءما معًا — customers.csv وorders.csv، export من CRM وexport من الفوترة — وتقرير مستحقّ يحتاجهما كملف واحد. لكن الـ emails مكتوبة بأحرف مختلفة، ومفتاح الـ join هو customer_id في أحدهما وcust_id في الآخر، ولصقهما بسذاجة إما يُسقِط صفوفًا بصمت أو يكرّرها. الـ join السيّئ أخطر أنواع أخطاء البيانات لأن النتيجة *تبدو* سليمة. هذا النظام يجعل الـ join صادقًا: نظّف المفاتيح، واعمل join على الـ id الصحيح، وأظهِر كل صف غير متطابق، وأثبِت أن الملف المدموج يُراجَع مقابل ما دخله.

جهّز هذا أولًا

  • الملفان، خامين — customers.csv وorders.csv — إضافة إلى الـ column الذي يربطهما وما إن كانت العلاقة واحد-لواحد أم واحد-لمتعدّد (عميل واحد، طلبات كثيرة).
  • ما الذي ينبغي أن يعنيه 'متطابق': id مضبوط تمامًا، أم تطابق تقريبي على email/الاسم حين لا يوجد id مشترك — وأي ملف هو مصدر الحقيقة حين يختلفان.
  • أعداد متوقّعة يمكنك التحقّق مقابلها: كم عميلًا، وكم طلبًا، وكم تقريبًا تتوقّع أن يتطابق — أهداف مراجعتك.

الـ workflow

  1. حلّل كلا الملفين وقارن مفاتيح الـ join

    قبل عمل join لأي شيء، انظر إلى المفاتيح جنبًا إلى جنب. اختلاف الأحرف أو المسافات أو الصيغ هو سبب 'الـ join فقد نصف صفوفي' — اصطَد مشاكل المفاتيح قبل أن تصير إسقاطات صامتة.

    أنت تطلب 
    افتح customers.csv وorders.csv. أظهر لي عدد صفوف كلٍّ منهما، ولمفاتيح الـ join — customer_id في customers وcust_id في orders — قارن صيغتيهما: حالة الأحرف، والأصفار البادئة، والمسافات، وأي قيم مشوّهة بوضوح. أخبرني كم مفتاحًا متمايزًا في كل ملف وكم منها يتداخل، قبل أن نغيّر أي شيء.

    ما تحصل عليه «customers: 4,200 صفًا، 4,200 قيمة customer_id متمايزة؛ orders: 9,850 صفًا، 3,980 قيمة cust_id متمايزة. customer_id بصيغة C00123؛ cust_id بصيغة 123 (لا بادئة، لا حشو) — لن يتطابقا حتى يُطبَّعا. نحو 3,900 يبدو أنها ستتداخل بمجرد محاذاة الصيغ».

    عدد التداخل هنا هو هدف مراجعتك. إن تطابق الـ join لاحقًا بعددٍ أقل بكثير من ~3,900، فثمّة شيء انكسر — وستعرف أن تبحث.

  2. وحّد المفاتيح على الجانبين

    طبّع أعمدة الـ join إلى صيغة قياسية واحدة قبل عمل الـ join — نفس الأحرف، نفس الحشو، مُشذّبة — واجعل Claude يُريك التحويل حتى تتحقّق أنه لم يشوّه قيمة حقيقية.

    أنت تطلب 
    وحّد المفاتيح كي تتطابق: انزع البادئة C والأصفار البادئة من customer_id، واقتطع المسافات، وحوّل أي columns للـ email إلى أحرف صغيرة. أظهر لي 5 أمثلة قبل/بعد لكل تحويل، ونبّهني على أي مفتاح يصير فارغًا أو يتصادم مع آخر بعد التنظيف. لا تعمل join بعد.

    ما تحصل عليه عيّنات قبل/بعد («C00123 ← 123؛ 'Bob@Acme.COM ' ← bob@acme.com») إضافة إلى قائمة تنبيهات: «قيمتا customer_id تصيران فارغتين بعد التجريد (كانتا أصفارًا كلها)؛ لا تصادمات». ترى بالضبط ما الذي تغيّر وما الذي كسره.

  3. اعمل join على الـ id الصحيح وأبرِز كل عدم تطابق

    نفّذ الـ join — لكن الصفوف غير المتطابقة هي المخرَج الحقيقي. الطلبات بلا عميل مطابق، والعملاء بلا طلبات: أظهِرها كلها، لأن الإسقاط الصامت هو كيف يكذب الـ join.

    أنت تطلب 
    الآن اعمل left-join لـ orders على customers بالمفتاح الموحّد، مع إبقائه صفًا واحدًا لكل طلب. ثم أعطني ثلاثة أعداد: الطلبات التي طابقت عميلًا، والطلبات التي بلا عميل مطابق (اسرد قيم cust_id تلك)، والعملاء الذين بلا طلبات على الإطلاق. لا تتخلّص من غير المتطابقة — ضع column باسم match_status على كل صف كي أراها.

    ما تحصل عليه «9,720 طلبًا تطابق؛ 130 طلبًا بلا عميل مطابق (قيم cust_id ‏7781، 7782، … — على الأرجح حسابات محذوفة)؛ 310 عملاء بلا طلبات. كل صف موسوم بـ matched / orphan_order / no_orders». الـ 130 يتيمة هي بالضبط ما كان join مُهمِل سيُخفيه.

    تلك الصفوف غير المتطابقة هي المغزى. الـ join الذي يُسقِط 130 طلبًا بصمت أسوأ من غياب join — يعطيك ملفًا نظيف المظهر وهو خاطئ بهدوء.

  4. راجع الملف المدموج مقابل المدخلات

    أثبِت أن الـ join حافظ على بياناتك. كل صف مُدخَل ينبغي أن يكون محسوبًا — متطابقًا، أو يتيمًا، أو مُفسَّرًا — والإجماليات (كالإيرادات) ينبغي أن تنجو من الـ join بلا تغيير.

    أنت تطلب 
    راجِع النتيجة مقابل المدخلات. هل matched + orphan_order يساوي صفوف الطلبات الأصلية البالغة 9,850؟ وهل مجموع مبالغ الطلبات في الملف المدموج يساوي المجموع في orders.csv الأصلي؟ إن لم يتوافق أي إجمالي، فجِد أين ذهبت الصفوف أو الدولارات. ثم احفظ الملف المدموج باسم customers_orders.csv مع إبقاء column الـ match_status.

    ما تحصل عليه «9,720 + 130 = 9,850 — كل الطلبات محسوبة. إجمالي الطلبات $1,284,500 في كلا الملفين — لا دولارات ضاعت في الـ join. حُفظ customers_orders.csv». الملف المدموج الآن يُراجَع حتى آخر سنت مقابل ما دخله.

اجعله ملكك

  • **لا id مشترك، فقط أسماء أو emails:** اطلب من Claude أن يعمل تطابقًا تقريبيًا (email بأحرف صغيرة، ثم الاسم + الشركة) و — وهذا حاسم — أن يُرجِع التطابقات غير المؤكّدة كقائمة 'تحتاج مراجعة' منفصلة ليؤكّدها إنسان، لا أن تُدمج بصمت أبدًا.
  • **أكثر من ملفين:** اعمل join لهم زوجًا تلو الآخر، مراجِعًا بعد كل join بدل مراجعتها كلها دفعةً واحدة — حتى حين يتوقّف إجمالي عن التوافق، تعرف بالضبط أي join كسره.
  • **هذا الـ join يجري كل شهر:** بمجرد أن تستقرّ قواعد التنظيف، احفظها كـ /merge custom command أو skill (انظر تبويب *Features*) — الملف المدموج المتكرّر الذي يُبنى عليه capstone درس *ابنِ تقرير تحليل متكرّرًا*.

انتبه إلى

  • الصفوف غير المتطابقة هي المُسلَّم، لا خطأ يُخفى. الـ join الذي 'نجح ببساطة' وأسقط 130 طلبًا بصمت هو أسوأ نتيجة هنا — اطلب دائمًا قائمة اليتامى وراجِع الأعداد.
  • إن كان أيٌّ من الملفين يحوي بيانات شخصية — emails، أسماء، معرّفات عملاء — نظّف واعمل join محليًا وأبقِ النتيجة على جهازك. التطابق التقريبي على الأسماء هو بالضبط حيث يمكن أن تدمج خطأً شخصين مختلفين، لذا وجّه التطابقات غير المؤكّدة إلى إنسان، لا تدمج تلقائيًا أبدًا.
  • يعمل Claude الـ join ويُبرِز عدم التطابقات؛ وأنت تملك أحكام التقدير — أي ملف يفوز في تعارض، وما إذا كان اليتيم مشكلة حقيقية أم حسابًا محذوفًا متوقّعًا. تحقّق من أن المراجعة تتوافق قبل أن تبني أي شيء على الملف المدموج.

ستحصل في النهاية على ملف `customers_orders.csv` واحد مدموج بمفاتيح موحّدة، وعمود `match_status` على كل صف، وقائمة صريحة بما لم يتطابق، وإجماليات تُراجَع حتى آخر سنت مقابل كلا المدخلين — dataset تثق به بما يكفي لتبني عليه تقريرًا.