تطوير قاعدة بيانات المعلوماتية الحيوية لأبحاث سندات الكبريتيد

تعد قاعدة بيانات المعلومات الحيوية لبنك بيانات البروتين (PDB) أكبر مستودع في العالم للهياكل المحددة تجريبياً للبروتينات والأحماض النووية والتجمعات المعقدة. يتم جمع جميع البيانات باستخدام طرق تجريبية مثل الأشعة السينية ، والتحليل الطيفي ، وعلم البلورات ، والرنين المغناطيسي النووي ، إلخ.

تشرح هذه المقالة كيفية استخراج البيانات وتصفيتها وتنظيفها من PDB. وهذا بدوره يتيح نوع التحليل الموضح في المقالة حدوث روابط ثاني كبريتيد البروتين في مجالات مختلفة من الحياة: مقارنة بين البروتينات من بنك بيانات البروتين ، المنشورة في هندسة البروتين والتصميم والاختيار ، المجلد 27 ، العدد 3 ، 1 مارس 2014 ، ص 65-72.

يحتوي PDB على الكثير من التراكيب المتكررة ذات الدقة والأساليب والطفرات المختلفة وما إلى ذلك. يمكن أن يؤدي إجراء تجربة باستخدام نفس البروتينات أو بروتينات مشابهة إلى تحيز في أي تحليل جماعي ، لذلك سنحتاج إلى اختيار الهيكل الصحيح من بين أي مجموعة من التكرارات . لهذا الغرض ، نحتاج إلى استخدام مجموعة البروتينات غير الزائدة عن الحاجة (NR).

لغرض التطبيع ، أوصي بتنزيل قاموس المركب الكيميائي لاستيراد أسماء الذرة إلى قاعدة بيانات تستخدم 3NF أو تستخدم مخططًا نجميًا ونمذجة الأبعاد. (لقد استخدمت أيضًا DSSP للمساعدة في التخلص من الهياكل الإشكالية. لن أغطي ذلك في هذه المقالة ، لكن لاحظ أنني لم أستخدم أي ميزات DSSP أخرى.)

تحتوي البيانات المستخدمة في هذا البحث على بروتينات أحادية الوحدة تحتوي على رابطة ثاني كبريتيد واحدة على الأقل مأخوذة من أنواع مختلفة. لإجراء تحليل ، يتم تصنيف جميع روابط ثاني كبريتيد أولاً على أنها متتالية أو غير متتالية ، حسب المجال (العتائق ، بدائيات النوى ، الفيروس ، حقيقيات النوى ، أو غير ذلك) ، وكذلك حسب الطول.

انتاج |

لكي تكون جاهزًا للإدخال في R أو SPSS أو بعض الأدوات الأخرى ، سيحتاج المحلل إلى أن تكون البيانات في جدول قاعدة بيانات بهذا الهيكل:

المواد والأساليب

من أجل تحقيق هذا الهدف ، فإن الخطوة الأولى هي جمع البيانات من rcsb.org. يحتوي هذا الموقع على هياكل PDB للتجارب بتنسيقات مختلفة قابلة للتنزيل.

على الرغم من تخزين البيانات بتنسيقات متعددة ، في هذا المثال ، سيتم استخدام التنسيق النصي المحدد بمساحة ثابتة فقط (PDB). من البدائل للتنسيق النصي PDB إصدار XML الخاص به ، PDBML ، ولكنه يحتوي أحيانًا على إدخالات غير صحيحة لتسمية موضع الذرة ، والتي يمكن أن تسبب مشاكل لتحليل البيانات. قد يتوفر أيضًا تنسيق MMCIF الأقدم وتنسيقات أخرى ، لكن لن يتم شرحها في هذه المقالة.

تنسيق PDB

تنسيق PDB هو تنسيق نصي مجزأ ذو عرض ثابت يمكن تحليله بسهولة عن طريق استعلامات SQL أو ملحقات Java أو وحدات Perl النمطية ، على سبيل المثال. يتم تمثيل كل نوع بيانات في حاوية الملف كسطر يبدأ بالعلامة المناسبة - سنتصفح كل نوع علامة في الأقسام الفرعية التالية. طول السطر أقل من أو يساوي 80 حرفًا ، حيث تأخذ العلامة ستة أحرف أو أقل بالإضافة إلى مسافة واحدة أو أكثر والتي تتطلب معًا ثمانية بايت. توجد أيضًا حالات بدون مسافات بين العلامات والبيانات ، عادةً لعلامات CONECT .

TITLE

تحدد علامة TITLE السطر باعتباره (جزءًا من) عنوان التجربة ، ويحتوي على اسم الجزيء والبيانات الأخرى ذات الصلة مثل إدخال حمض أميني معين أو تحوره أو حذفه.

 12345678901234567890123456789012345678901234567890123456789012345678901234567890 TITLE A TWO DISULFIDE DERIVATIVE OF CHARYBDOTOXIN WITH DISULFIDE TITLE 2 13-33 REPLACED BY TWO ALPHA-AMINOBUTYRIC ACIDS, NMR, 30 TITLE 3 STRUCTURES

في حالة وجود عدة أسطر لسجل TITLE ، يجب أن يكون العنوان متسلسلًا ، مرتبًا برقم متابعة ، يتم وضعه ، بمحاذاة لليمين ، على البايتين 9 و 10 (اعتمادًا على عدد هذه السطور).

ATOM

البيانات المخزنة في خطوط ATOM هي تنسيق البيانات لكل ذرة في التجربة. في بعض الأحيان تحتوي التجربة على إدخالات أو طفرات أو مواقع بديلة أو نماذج متعددة. ينتج عن هذا تكرار نفس الذرة عدة مرات. اختيار الذرات الصحيحة سيتم شرحه لاحقًا.

 12345678901234567890123456789012345678901234567890123456789012345678901234567890 ATOM 390 N GLY A 26 -1.120 -2.842 4.624 1.00 0.00 N ATOM 391 CA GLY A 26 -0.334 -2.509 3.469 1.00 0.00 C ATOM 392 C GLY A 26 0.682 -1.548 3.972 1.00 0.00 C ATOM 393 O GLY A 26 0.420 -0.786 4.898 1.00 0.00 O ATOM 394 H GLY A 26 -0.832 -2.438 5.489 1.00 0.00 H ATOM 395 HA2 GLY A 26 0.163 -3.399 3.111 1.00 0.00 H ATOM 396 HA3 GLY A 26 -0.955 -2.006 2.739 1.00 0.00 H

المثال أعلاه مأخوذ من التجربة 1BAH . يشير العمود الأول إلى نوع السجل ، بينما يمثل العمود الثاني الرقم التسلسلي للذرة. كل ذرة في الهيكل لها رقم تسلسلي خاص بها.

بجانب الرقم التسلسلي يوجد ملصق موضع الذرة ، والذي يأخذ أربعة بايت. من هذا الموضع الذري ، من الممكن استخراج الرمز الكيميائي للعنصر ، والذي لا يوجد دائمًا في بيانات التسجيل في عمود منفصل خاص به.

بعد اسم الذرة يوجد رمز بقايا مكون من ثلاثة أحرف. في حالة البروتينات ، تتوافق هذه البقايا مع حمض أميني. بعد ذلك ، السلسلة مشفرة بحرف واحد. نعني بالسلسلة سلسلة واحدة من الأحماض الأمينية ، مع وجود فجوات أو بدونها ، على الرغم من أنه في بعض الأحيان يمكن تخصيص الروابط لسلسلة ؛ يمكن اكتشاف هذه الحالة من خلال فجوات كبيرة جدًا في تسلسل الأحماض الأمينية الموجودة في العمود التالي. في بعض الأحيان يمكن فحص نفس الهيكل مع تضمين الطفرات ، وفي هذه الحالة يتوفر رمز الإدراج في عمود إضافي بعد عمود التسلسل. يحتوي رمز الإدخال على حرف للمساعدة في التمييز بين البقايا المتأثرة.

الأعمدة الثلاثة التالية هي الإحداثيات المكانية لكل ذرة ، مقاسة بوحدة أنجستروم (Å). بجانب هذه الإحداثيات يوجد عمود الشغل ، الذي يوضح احتمالية وجود الذرة في ذلك المكان ، على المقياس المعتاد من صفر إلى واحد.

العمود الثاني الأخير هو عامل درجة الحرارة ، والذي يحمل معلومات حول الاضطراب في البلورة ، مقاسة بـ ². تشير القيمة الأكبر من 60 درجة مئوية إلى الاضطراب ، بينما تشير القيمة الأقل من 30 درجة مئوية إلى الثقة. لا يوجد دائمًا في ملفات PDB لأنه يعتمد على الطريقة التجريبية.

الأعمدة التالية - الرمز والشحنة - مفقودة عادةً. يمكن جمع الرمز الكيميائي من عمود موضع الذرة ، كما ذكرنا أعلاه. عندما تكون الشحنة موجودة ، يتم لصقها بالرمز كعدد صحيح متبوعًا بعلامة + أو - ، على سبيل المثال N1+ .

TER

هذا يمثل نهاية السلسلة. حتى بدون هذا الخط ، من السهل التمييز حيث تنتهي السلسلة. وبالتالي ، غالبًا ما يكون خط TER مفقودًا.

MODEL و ENDMDL

يشير خط MODEL إلى مكان بدء نموذج الهيكل ، ويحتوي على الرقم التسلسلي للنموذج.

بعد كل الخطوط الذرية في هذا النموذج ، تنتهي بخط ENDMDL .

SSBOND

تحتوي هذه الخطوط على روابط ثنائي كبريتيد بين الأحماض الأمينية السيستين. يمكن أن توجد روابط ثاني كبريتيد في أنواع المخلفات الأخرى ، ولكن في هذه المقالة سيتم تحليل الأحماض الأمينية فقط ، لذلك يتم تضمين السيستين فقط. المثال التالي مأخوذ من تجربة الكود 132L :

 12345678901234567890123456789012345678901234567890123456789012345678901234567890 SSBOND 1 CYS A 6 CYS A 127 1555 1555 2.01 SSBOND 2 CYS A 30 CYS A 115 1555 1555 2.05 SSBOND 3 CYS A 64 CYS A 80 1555 1555 2.02 SSBOND 4 CYS A 76 CYS A 94 1555 1555 2.02

في هذا المثال ، توجد أربع روابط ثنائي كبريتيد تم تمييزها في الملف برقمها التسلسلي في العمود الثاني. تستخدم كل هذه الروابط السيستين (العمودين 3 و 6) ، وكلها موجودة في السلسلة A (العمودين 4 و 7). بعد كل سلسلة يوجد رقم تسلسل بقايا يشير إلى موضع الرابطة في سلسلة الببتيد. توجد أكواد الإدراج بجوار كل تسلسل بقايا ، لكنها غير موجودة في هذا المثال لعدم وجود حمض أميني مُدرج في تلك المنطقة. يتم حجز العمودين قبل الأخير لعمليات التناظر ، والعمود الأخير هو المسافة بين ذرات الكبريت ، مقاسة بـ.

لنأخذ لحظة لإعطاء بعض السياق لهذه البيانات.

توضح الصور أدناه ، المأخوذة باستخدام عارض rcsb.org NGL ، بنية التجربة 132L . على وجه الخصوص ، تظهر بروتينًا بدون روابط. تستخدم الصورة الأولى تمثيل العصا ، مع تلوين CPK يُظهر الكبريت وروابطه باللون الأصفر. تمثل وصلات الكبريت على شكل V وصلات الميثيونين ، في حين أن الوصلات على شكل Z عبارة عن روابط ثنائي كبريتيد بين السيستين.

في الصورة التالية ، تظهر طريقة مبسطة لتصور البروتين تسمى تصور العمود الفقري ملونة بواسطة الأحماض الأمينية ، حيث تكون السيستين صفراء. إنه يمثل نفس البروتين ، مع استبعاد سلسلته الجانبية ، وشمل جزء فقط من مجموعة الببتيد - في هذه الحالة ، العمود الفقري للبروتين. إنها مكونة من ثلاث ذرات: N-terminal و C-alpha و C-terminal. لا تُظهر هذه الصورة روابط ثاني كبريتيد ، لكنها مبسطة لإظهار الترتيب المكاني للبروتين:

يتم إنشاء الأنابيب عن طريق ضم ذرات مرتبطة بالببتيد مع ذرة C-alpha. لون السيستين هو نفسه لون الكبريت في طريقة تلوين CPK. عندما تقترب السيستين بما فيه الكفاية ، فإن الكبريتات الخاصة بها تخلق روابط ثاني كبريتيد ، وهذا يقوي الهيكل. وإلا فإن هذا البروتين سوف يرتبط كثيرًا ، وسيكون هيكله أقل استقرارًا في درجات الحرارة المرتفعة.

CONECT

تستخدم هذه السجلات لتمييز الاتصالات بين الذرات. في بعض الأحيان لا تكون هذه العلامات موجودة على الإطلاق ، بينما في أحيان أخرى يتم ملء جميع البيانات. في حالة تحليل روابط ثاني كبريتيد ، يمكن أن يكون هذا الجزء مفيدًا - ولكنه ليس ضروريًا. هذا لأنه ، في هذا المشروع ، تتم إضافة السندات غير الموسومة عن طريق قياس المسافات ، لذلك سيكون هذا عبئًا ، ويجب أيضًا التحقق منه.

SOURCE

تحتوي هذه السجلات على معلومات حول الكائن المصدر الذي تم استخلاص الجزيء منه. تحتوي على سجلات فرعية لتسهيل الموقع في التصنيف ، ولها نفس البنية متعددة الأسطر التي رأيناها مع سجلات العنوان.

 SOURCE MOL_ID: 1; SOURCE 2 ORGANISM_SCIENTIFIC: ANOPHELES GAMBIAE; SOURCE 3 ORGANISM_COMMON: AFRICAN MALARIA MOSQUITO; SOURCE 4 ORGANISM_TAXID: 7165; SOURCE 5 GENE: GST1-6; SOURCE 6 EXPRESSION_SYSTEM: ESCHERICHIA COLI; SOURCE 7 EXPRESSION_SYSTEM_TAXID: 562; SOURCE 8 EXPRESSION_SYSTEM_STRAIN: BL21(DE3)PLYSS; SOURCE 9 EXPRESSION_SYSTEM_VECTOR_TYPE: PLASMID; SOURCE 10 EXPRESSION_SYSTEM_PLASMID: PXAGGST1-6

تنسيق NR

هذه قائمة بمجموعات PDB المتسلسلة غير الزائدة عن الحاجة (NR). يمكن العثور على لقطاتها على ftp.ncbi.nih.gov/mmdb/nrtable/. والغرض منه هو تجنب التحيزات غير الضرورية التي يسببها تشابه البروتين. يحتوي NR على ثلاث مجموعات مع مستويات مختلفة للقيمة p للهوية تم إنشاؤها عن طريق مقارنة جميع هياكل PDB. تُضاف النتيجة إلى الملفات النصية والتي سيتم شرحها لاحقًا. ليست كل الأعمدة مطلوبة لهذا المشروع ، لذلك سيتم شرح الأعمدة المهمة فقط.

يحتوي العمودان الأولان على رمز تجربة PDB الفريد ومعرف السلسلة كما هو موضح لسجلات ATOM أعلاه. تحتوي الأعمدة 6 و 9 و C على معلومات حول تمثيل القيمة p ، وهو مستوى تشابه التسلسلات المحسوبة بواسطة BLAST. إذا كانت هذه القيمة صفرًا ، فلا يُقبل أن تكون جزءًا من مجموعة ؛ إذا كانت القيمة 1 ، فهي كذلك. تمثل الأعمدة المذكورة قبول المجموعات ذات القيم p من 10e-7 و 10e-40 و 10e-80 ، على التوالي. لن يتم استخدام سوى المجموعات ذات الحد الفاصل للقيمة p 10e-7 للتحليل.

يحتوي العمود الأخير على معلومات حول قبول الهيكل ، حيث يكون a مقبولاً و n غير مقبول.

 #--------------------------------------------------------------------------------------------------------------------------- # 1 2 3 4 5 6 7 8 9 ABCDEFGHIJKLMNOPQ #--------------------------------------------------------------------------------------------------------------------------- 3F8V A 69715 1 1 1 1 1 1 1 1 1 9427 1 1 0.00 0.00 0.00 0.00 1.08 1 6 5 164 X a 3DKE X 68132 1 2 0 1 2 0 1 2 0 39139 1 1 0.00 0.00 0.00 0.00 1.25 1 11 7 164 X a 3HH3 A 77317 1 3 0 1 3 0 1 3 0 90 1 0 0.00 0.00 0.00 0.00 1.25 1 5 4 164 X a 3HH5 A 77319 1 4 0 1 4 0 1 4 0 90 2 0 0.00 0.00 0.00 0.00 1.25 1 4 4 164 X a

بناء قاعدة البيانات وتحليل البيانات

الآن بعد أن أصبح لدينا فكرة عما نتعامل معه وما يتعين علينا القيام به ، فلنبدأ.

تنزيل البيانات

يمكن العثور على جميع البيانات الخاصة بهذا التحليل على العناوين الثلاثة التالية:

• ftp.wwpdb.org/pub/pdb/data/structures/divided/pdb/
• ftp.ncbi.nih.gov/mmdb/nrtable/
• ftp.ncbi.nih.gov/pub/taxonomy/taxdmp.zip

أول رابطين يحتويان على قائمة من المحفوظات. يجب استخدام أحدث أرشيف من كل منها لتجنب المشاكل الناجمة عن نقص الدقة أو الجودة. يحتوي الارتباط الثالث على أرشيف التصنيف الأحدث مباشرة.

إعراب البيانات

عادةً ما يتم تحليل ملفات PDB عن طريق المكونات الإضافية أو الوحدات النمطية في Java أو Perl أو Python. في حالة هذا البحث ، كتبت تطبيق Perl مخصصًا بدون استخدام وحدة تحليل PDB مكتوبة مسبقًا. والسبب في ذلك هو عند تحليل كمية كبيرة من البيانات ، من واقع خبرتي ، أن المشكلة الأكثر شيوعًا في استخدام البيانات التجريبية هي الأخطاء في البيانات. في بعض الأحيان توجد أخطاء في الإحداثيات ، والمسافات ، وأطوال الخطوط ، والتعليقات في الأماكن التي لا ينبغي أن تكون فيها ، وما إلى ذلك.

الطريقة الأكثر فعالية للتعامل مع هذا هي تخزين كل شيء في قاعدة البيانات كنص خام في البداية. تتم كتابة المحللون اللغويون الشائعون للتعامل مع البيانات المثالية التي تتوافق تمامًا مع المواصفات. لكن من الناحية العملية ، البيانات ليست مثالية ، وسيتم شرح ذلك في قسم التصفية حيث ستجد البرنامج النصي لاستيراد Perl.

بناء قاعدة البيانات

عند إنشاء قاعدة البيانات ، لاحظ أن قاعدة البيانات هذه مبنية لمعالجة البيانات. سيتم إجراء تحليل لاحق في SPSS أو R. لأغراضنا هنا يوصى باستخدام PostgreSQL مع الإصدار 8.4 على الأقل.

يتم نسخ هيكل الجدول مباشرة من الملفات التي تم تنزيلها مع بعض التغييرات الصغيرة فقط. في هذه الحالة ، يكون عدد السجلات صغيرًا جدًا بحيث لا يستحق قضاء وقتنا في التطبيع. كما ذكرنا سابقًا ، قاعدة البيانات هذه للاستخدام الفردي فقط: لم يتم إنشاء هذه الجداول ليتم عرضها على موقع ويب - فهي موجودة فقط لمعالجة البيانات. بمجرد الانتهاء من ذلك ، يمكن إسقاطها أو نسخها احتياطيًا كبيانات تكميلية ، ربما لتكرار العملية من قبل باحث آخر.

في هذه الحالة ، ستكون النتيجة النهائية هي جدول واحد يمكن بعد ذلك تصديره إلى ملف لاستخدامه مع بعض الأدوات الإحصائية مثل SPSS أو R.

الجداول

يجب أن يكون استخراج البيانات من سجلات ATOM متصلاً بسجلات HEADER أو TITLE . تم شرح التسلسل الهرمي للبيانات في الصورة أدناه.

نظرًا لأن هذه الصورة عبارة عن تمثيل مبسط لقاعدة بيانات في النموذج العادي الثالث (3NF) ، فهي تحتوي على الكثير من النفقات العامة لأغراضنا. السبب: لحساب المسافة بين الذرات لاكتشاف رابطة ثاني كبريتيد ، نحتاج إلى القيام بوصلات. في هذه الحالة ، سيكون لدينا جدول متصل مرتين ، وأيضًا تم ربطه بهيكل ثانوي وأساسي مرتين لكل منهما ، وهي عملية بطيئة جدًا. نظرًا لأن كل تحليل لا يحتاج إلى معلومات بنية ثانوية ، فقد تم اقتراح مخطط آخر في حالة احتياجك إلى إعادة استخدام البيانات أو تحليل كميات أكبر من روابط ثاني كبريتيد:

سندات ثاني كبريتيد ليست متكررة مثل الروابط التساهمية الأخرى ، لذلك ليست هناك حاجة إلى نموذج المستودع ، على الرغم من أنه يمكن استخدامه. سيستغرق تطوير المخطط النجمي والنمذجة الأبعاد أدناه وقتًا طويلاً للغاية ، وسيزيدان من تعقيد الاستعلامات:

في الحالات التي يتعين فيها معالجة جميع السندات ، فإنني أوصي بمخطط النجوم.

(وإلا فهي ليست ضرورية ، لأن روابط ثاني كبريتيد ليست شائعة مثل الروابط الأخرى. في حالة هذا العمل ، يكون عدد روابط ثاني كبريتيد قريبًا من 30000 ، والذي قد يكون سريعًا بدرجة كافية في 3NF ، لكنني قررت معالجته عبر جدول غير طبيعي ، لذا لم يتم تصويره هنا.)

العدد الإجمالي المتوقع لجميع الروابط التساهمية هو على الأقل ضعف عدد الذرات في البنية الثلاثية ، وفي هذه الحالة سيكون 3NF بطيئًا جدًا ، لذلك يلزم إلغاء التطابق باستخدام شكل مخطط النجم. في هذا المخطط ، تحتوي بعض الجداول على فحصين خارجيين للمفاتيح ، وذلك بسبب إنشاء رابطة بين ذرتين ، لذلك يجب أن يكون لكل ذرة atom_name_id primary_structure_id و residue_id .

هناك طريقتان لملء جدول أبعاد d_atom_name : من البيانات ، ومن مصدر آخر ، قاموس المكون الكيميائي الذي ذكرته سابقًا. تنسيقه مشابه لتنسيق PDB: فقط خطوط RESIDUE و CONECT مفيدة. هذا لأن العمود الأول لـ RESIDUE يحتوي على رمز مكون من ثلاثة أحرف متبقية ، ويحتوي CONECT على اسم الذرة ووصلاتها ، وهي أيضًا أسماء ذرية. لذلك من هذا الملف ، يمكننا تحليل جميع أسماء atom وإدراجها في قاعدة البيانات الخاصة بنا ، على الرغم من أنني أوصيك بالسماح بإمكانية احتواء قاعدة البيانات على أسماء atom غير مدرجة.

 RESIDUE PRO 17 CONECT N 3 CA CD H CONECT CA 4 NC CB HA CONECT C 3 CA O OXT CONECT O 1 C CONECT CB 4 CA CG HB2 HB3 CONECT CG 4 CB CD HG2 HG3 CONECT CD 4 N CG HD2 HD3 CONECT OXT 2 C HXT CONECT H 1 N CONECT HA 1 CA CONECT HB2 1 CB CONECT HB3 1 CB CONECT HG2 1 CG CONECT HG3 1 CG CONECT HD2 1 CD CONECT HD3 1 CD CONECT HXT 1 OXT END HET PRO 17 HETNAM PRO PROLINE FORMUL PRO C5 H9 N1 O2

في هذا المشروع ، تعتبر سرعة التشفير أكثر أهمية من سرعة التنفيذ واستهلاك التخزين. قررت عدم التطبيع — بعد كل شيء ، هدفنا هو إنشاء جدول بالأعمدة المذكورة في المقدمة.

في هذا الجزء ، سيتم شرح الجداول الأكثر أهمية فقط.

الجداول الرئيسية هي:

• proteins : جدول بأسماء ورموز التجربة.
• ps : جدول الهيكل الأساسي الذي سيحتوي على sequence و chain_id و code .
• ts : جدول يحتوي على هيكل ثلاثي / رباعي مستخرج من البيانات الخام وتحويله إلى تنسيق سجل ATOM . سيتم استخدام هذا كجدول مرحلي ، ويمكن إسقاطه بعد الاستخراج. يتم استبعاد الروابط.
• sources : قائمة الكائنات الحية التي تم اشتقاق البيانات التجريبية منها.
• tax_names ، و taxonomy_path ، و taxonomy_paths : أسماء تصنيف Linnean من قاعدة بيانات تصنيف NCBI ، تُستخدم للحصول على مسارات التصنيف من الكائنات المدرجة في sources .
• nr : قائمة البروتينات غير الزائدة عن الحاجة NCBI المستخرجة من مجموعة NR.
• pdb_ssbond : قائمة روابط ثاني كبريتيد في ملف PDB محدد.

تصفية البيانات ومعالجتها

يتم استرداد البيانات من اللقطات من مستودع RCSB PDB.

يتم استيراد كل ملف إلى جدول واحد raw_pdb في قاعدة بيانات PostgreSQL الخاصة بنا باستخدام برنامج نصي Perl. يستخدم البرنامج النصي معاملات 10000 إدراج لكل قطعة.

هيكل raw_pdb هو:

يبدو نص الاستيراد كما يلي:

 #!/usr/bin/perl -w use FindBin '$Bin'; use DBI; $dbName = 'bioinf'; $dbLogin = 'ezop'; $dbPass = 'XYZ'; $conn = DBI->connect("DBI:Pg:database=$dbName;host=localhost", "$dbLogin", "$dbPass", {'RaiseError' => 1, 'AutoCommit' => 0}); die "./pdb_lines_unos.pl <table> <file>" if not defined($ARGV[0]); $recordCount = 0; $table = $ARGV[0]; $fName = $ARGV[1]; open F, "zcat $fName|"; while (<F>) { chomp; $linija = $_; $recordCount += 1; $sql = "insert into $table (code, line_num, line_cont) values (?, ?, ?)"; $conn->do($sql, undef, $fName, $recordCount, $linija); $conn->commit() if ($recordCount%10000 == 0); } close F; $conn->commit(); 1;

بعد استيراد السطور ، يتم تحليلها باستخدام الوظائف التي سنحددها أدناه.

من بيانات raw_pdb ، نقوم بإنشاء الجداول ts و ps proteins sources و sources_organela و ss_bond عن طريق تحليل السجلات المقابلة.

يحتوي جدول ps على ثلاثة أعمدة مهمة: chain length sequence . يتم إنشاء تسلسل البروتين باستخدام ذرات C-alpha لكل سلسلة ولكل بقايا مرتبة حسب تسلسل البقايا ، مع الأخذ فقط الإدخال الأول والموقع البديل الأول. chain مأخوذة من عمود TS.chain ، length هو ببساطة الطول المحسوب مسبقًا لسلسلة sequence . نظرًا لأن هذه المقالة تهدف إلى تحليل السلاسل الفردية والوصلات داخل السلسلة فقط ، يتم تخطي البروتينات متعددة السلاسل في تحليلنا هنا.

ضمن سجلات SSBOND ، يتم تخزين جميع روابط ثاني كبريتيد في جدول pdb_ssbond ، الذي يرث من جدول pdb_ssbond_extended . يبدو pdb_ssbond كما يلي:

لقد أضفت أيضًا هذه الفهارس:

 "pdb_ssbond_pkey" PRIMARY KEY, btree (id) "ndxcode1" btree (code, chain_id1, res_seq1) "ndxcode2" btree (code, chain_id2, res_seq2)

من المفترض أن توزيع روابط ثاني كبريتيد قبل القطع هو Gaussian (بدون اختبار ، على سبيل المثال ، اختبار KS) ، لذلك تم حساب الانحرافات المعيارية على كل مسافة بين السيستين في نفس البروتين لاكتشاف نطاق أطوال الرابطة المسموح بها ومقارنتها لقطع. كان القطع هو نفسه متوسط ​​الانحراف المعياري المحسوب زائد ناقص ثلاثة. لقد قمنا بتوسيع النطاق لتقديم المزيد من روابط ثاني كبريتيد المحتملة والتي لم يتم إدراجها في ملف PDB في صفوف SSBOND ولكننا قمنا بإدراج أنفسنا عن طريق حساب المسافات بين سجلات ATOM . النطاق المختار لـ ssbonds يتراوح بين 1.6175344456264 و 2.48801947642267 Å ، وهو المتوسط ​​(2.05) زائد ناقص أربعة انحرافات معيارية:

 select count(1) as cnt , stddev(dist) as std_dev , avg(dist) as avg_val , -stddev(dist) + avg(dist) as left1 , stddev(dist) + avg(dist) as right1 , -2 * stddev(dist) + avg(dist) as left2 , 2 * stddev(dist) + avg(dist) as right2 , -3 * stddev(dist) + avg(dist) as left3 , 3 * stddev(dist) + avg(dist) as right3 , -4 * stddev(dist) + avg(dist) as left4 , 4 * stddev(dist) + avg(dist) as right4 , min(dist) , max(dist) from pdb_ssbond_tmp where dist > 0 and dist < 20;

يحتوي جدول TS على إحداثيات جميع الذرات ، ولكن سيتم استخدام السيستين فقط ، مع الكبريت المسمى " SG " . لذلك يتم إنشاء جدول مرحلي آخر يحتوي على ذرات الكبريت " SG " فقط لتسريع العملية عن طريق تقليل عدد السجلات المراد البحث عنها. عند اختيار الكبريت فقط ، يكون عدد التوليفات أقل بكثير مما هو عليه في حالة جميع الذرات — 194.574 من الأولى مقارنة بـ 122.761.100 من الثانية. ضمن هذا الجدول المرتبط بنفسه ، يتم حساب المسافات باستخدام المسافة الإقليدية ، ويتم استيراد النتائج إلى جدول pdb_ssbond ولكن فقط عندما تكون المسافة بين الأطوال المحددة المحسوبة مسبقًا. والسبب في إجراء هذا التسريع هو تقليل مقدار الوقت اللازم لتشغيل العملية بأكملها مرة أخرى - للتحقق من الأغراض - وإبقائها في غضون يوم واحد.

لتنظيف روابط ثاني كبريتيد ، نستخدم الخوارزمية التالية:

• احذف عندما يشير كلا جانبي الاتصال إلى نفس الحمض الأميني
• تحذف السندات التي لا يتراوح طولها بين 1.6175344456264 و 2.48801947642267
• قم بإزالة الإدخالات
• قم بإزالة الروابط الناتجة عن مواقع الذرة البديلة ، مع ترك الموقع الأول

الكود الخاص بهذا (أخذ الجدول pdb_ssbond كوسيطة أولى) هو:

 CREATE OR REPLACE FUNCTION pdb_ssbond_clean2( clean_icodes boolean, clean_altloc boolean, mark_reactive boolean, mark_consecutive boolean) RETURNS void AS $$ declare _res integer; BEGIN delete from pdb_ssbond b where exists ( select a.id from pdb_ssbond a where a.code = b.code and a.id > b.id and ( ( a.chain_id1 = b.chain_id1 and a.res_seq1 = b.res_seq1 and a.chain_id2 = b.chain_id2 and a.res_seq2 = b.res_seq2) or ( a.chain_id1 = b.chain_id2 and a.res_seq1 = b.res_seq2 and a.chain_id2 = b.chain_id1 and a.res_seq2 = b.res_seq1) ) ) ; delete from pdb_ssbond where chain_id1 = chain_id2 and res_seq1 = res_seq2 and i_code1 = i_code2; update pdb_ssbond set is_consecutive = true , is_reactive = false; delete from pdb_ssbond where not dist between 1.6175344456264 and 2.48801947642267; if clean_icodes then delete from pdb_ssbond where i_code1 not in ('', ' ', 'A') or i_code2 not in ('', ' ', 'A') ; end if; if clean_altloc then delete from pdb_ssbond a where exists ( select 1 from pdb_ssbond b where b.code = a.code and b.chain_id1 = a.chain_id1 and b.res_seq1 = a.res_seq1 and b.i_code1 = a.i_code1 and b.ser_num < a.ser_num ) ; delete from pdb_ssbond a where exists ( select 1 from pdb_ssbond b where b.code = a.code and b.chain_id2 = a.chain_id2 and b.res_seq2 = a.res_seq2 and b.i_code2 = a.i_code2 and b.ser_num < a.ser_num ) ; end if; if mark_reactive then update pdb_ssbond set is_reactive = false ; update pdb_ssbond set is_reactive = true where exists ( select 1 from pdb_ssbond b where b.code = pdb_ssbond.code and b.chain_id1 = pdb_ssbond.chain_id1 and b.res_seq1 = pdb_ssbond.res_seq1 and b.i_code1 = pdb_ssbond.i_code1 and b.ser_num < pdb_ssbond.ser_num ) ; update pdb_ssbond set is_reactive = true where exists ( select 1 from pdb_ssbond b where b.code = pdb_ssbond.code and b.chain_id2 = pdb_ssbond.chain_id2 and b.res_seq2 = pdb_ssbond.res_seq2 and b.i_code2 = pdb_ssbond.i_code2 and b.ser_num < pdb_ssbond.ser_num ) ; update pdb_ssbond set is_reactive = true where (code, chain_id1, res_seq1, i_code1) in ( select code, chain_id1 as c, res_seq1 as r, i_code1 as i from pdb_ssbond intersect select code, chain_id2 as c, res_seq2 as r, i_code2 as i from pdb_ssbond ) ; update pdb_ssbond set is_reactive = true where (code, chain_id2, res_seq2, i_code2) in ( select code, chain_id1 as c, res_seq1 as r, i_code1 as i from pdb_ssbond intersect select code, chain_id2 as c, res_seq2 as r, i_code2 as i from pdb_ssbond ); end if; if mark_consecutive then update pdb_ssbond set is_consecutive = false; update pdb_ssbond set is_consecutive = true where not exists ( select 1 from pdb_ssbond a where a.code = pdb_ssbond.code and ( (a.chain_id1 = pdb_ssbond.chain_id1 and a.chain_id2 = pdb_ssbond.chain_id2) or (a.chain_id1 = pdb_ssbond.chain_id2 and a.chain_id2 = pdb_ssbond.chain_id1) ) and ( (a.res_seq1 between pdb_ssbond.res_seq1 and pdb_ssbond.res_seq2) or (a.res_seq2 between pdb_ssbond.res_seq1 and pdb_ssbond.res_seq2) or (pdb_ssbond.res_seq1 between a.res_seq1 and a.res_seq2) or (pdb_ssbond.res_seq2 between a.res_seq1 and a.res_seq2) ) and not ( a.code = pdb_ssbond.code and a.chain_id1 = pdb_ssbond.chain_id1 and a.chain_id2 = pdb_ssbond.chain_id2 and a.res_seq1 = pdb_ssbond.res_seq1 and a.res_seq2 = pdb_ssbond.res_seq2 ) ); end if; END; $$ LANGUAGE plpgsql;

باستخدام هذا ، يتم استيراد مجموعة البروتينات غير الزائدة عن الحاجة إلى جدول nr الذي يتم ربطه بجداول ps وجداول proteins ، ويتم تمييز المجموعات ( set7 و set40 و set80 ). في النهاية ، وفقًا لكمية البروتين ، سيتم تحليل مجموعة واحدة فقط. تتم إزالة السلاسل غير المتطابقة بين PDB و NR من التحليل.

يتم استبعاد البروتينات التي لا تحتوي على روابط ثاني كبريتيد من البحث ، بالإضافة إلى البروتينات التي لا تنتمي إلى أي مجموعة. تتم معالجة البيانات باستخدام DSSP ، ويتم أيضًا استبعاد هذه الملفات التي كانت بها مشاكل في الدقة أو عدد كبير جدًا من الذرات لتتم معالجتها. يتم استخدام البروتينات ذات السلاسل المفردة فقط كنتيجة للتحليل لأنه لم يتم الاحتفاظ بالاتصالات بين السلسلة ، على الرغم من أنه يمكن حسابها بسهولة من جدول ssbond عن طريق حساب عدد الاتصالات التي لها سلاسل مختلفة.

بالنسبة للبروتينات المتبقية ، يتم إجراء تحديث للعدد الإجمالي للروابط وعدد الروابط المتداخلة ، ويتم ذلك لكل مجموعة من المجموعات.

يتم استخراج كائن المصدر من سجلات SOURCE . في الحالات التي يكون فيها غير معروف ، أو اصطناعي ، أو مصمم ، أو اصطناعي ، أو هجين ، يتم تجاهله من البحث. يتم أيضًا استبعاد البروتينات منخفضة الدقة فقط عندما تكون سلسلتها الجانبية غير مرئية.

يتم تخزين سجلات SOURCE في جدول sources ، الذي يحتوي على صفوف التصنيف. في بعض الحالات ، يكون التصنيف مفقودًا أو غير صحيح. في هذه الحالات ، هناك حاجة إلى التصحيح اليدوي للخبراء.

من المصدر والتصنيف الذي تم تنزيله من NCBI ، يتم تعيين الفئة لكل بنية أساسية. في حالة عدم التمكن من تخصيص فئة ، تتم إزالة البروتين من قائمة التحليل. مع العلم أنه يتم استخدام قواعد البيانات البيولوجية ، يوصى بإجراء فحص إضافي لجميع سجلات المصدر وفئات تصنيف NCBI بواسطة عالم أحياء ، وإلا فقد تكون هناك مشاكل في التصنيفات بين المجالات المختلفة. لمطابقة المواقع الخلوية المصدر بمعرفات التصنيف ، يتم استخراج البيانات من الجدول المصدر إلى الجدول sources_organela حيث تتم كتابة جميع البيانات كرمز وعلامة وقيمة. شكله موضح أدناه:

 select * from sources_organela where code = '1rav';

أرشيف التصنيف الذي نريد استخدامه هو ملف مضغوط يحتوي على سبعة ملفات تفريغ. من بين هذه الملفات ، اثنان من أهم الملفات هما names.dmp و merged.dmp . كلا الملفين عبارة عن ملفين محددين بعلامات تبويب CSV كما هو مفصل في الوثائق:

• يحتوي الملف merged.dmp على قائمة بمعرفات التصنيف السابقة ومعرفات التصنيف الحالية التي تم دمج كل منها.
• يحتوي names.dmp على هذه الأعمدة المهمة بهذا الترتيب:
  • tax_id : معرّف التصنيف
  • name_txt : اسم النوع ، وإذا أمكن ، الاسم الفريد (حيث يمكن العثور على الأنواع بأسماء متعددة ، وهذا يساعد في توضيح)
• يحتوي division.dmp على أسماء نطاقات المستوى الأعلى التي سنستخدمها كفئاتنا.
• nodes.dmp هو الجدول الذي يحتوي على بنية هرمية للكائنات باستخدام معرفات التصنيف.
  • يحتوي على معرف التصنيف الأصلي ، وهو مفتاح خارجي يمكن العثور عليه في names.dmp .
  • يحتوي أيضًا على معرّف قسم مهم بالنسبة لنا لتخزين بيانات النطاق الأعلى ذات الصلة بشكل صحيح.

مع كل هذه البيانات والتصحيحات اليدوية (تحديد مجالات الحياة الصحيحة) تمكنا من إنشاء هيكل جدول taxonomy_path . تبدو عينة البيانات كما يلي:

 select * from taxonomy_path order by length(path) limit 20 offset 2000;

Before any analysis, to avoid biases, sequences have to be checked for their level of identity. Although the NR set contains sequences which are already compared between each other, an extra check is always recommended.

For each disulfide bond's prior statistical analysis, data is marked if it is reactive or overlapping. After marking overlaps, that information automatically reveals how many consecutive and non-consecutive bonds are inside each protein, and that data is stored in the proteins table from which all protein complexes are excluded in final result.

Each disulfide bond is marked also for its association to sets, by checking both bond sides to see if they belong to the same NR set. Where that is not the case, the disulfide bond is skipped for that set analysis.

To analyze the quantity of bonds by their variance, each length has to be put in a specific class. In this case, only five classes are chosen as written in the function below.

 CREATE OR REPLACE FUNCTION len2class(len integer) RETURNS integer AS $BODY$ BEGIN return case when len <= 100 then 1 when len > 100 and len <= 200 then 2 when len > 200 and len <= 300 then 3 when len > 300 and len <= 400 then 4 else 5 end; END; $BODY$ LANGUAGE plpgsql VOLATILE COST 100;

Most of the protein sizes are less than 400 amino acids, so length classification is done by splitting lengths into five ranges, each taking 100 amino acids, except the last one which takes the rest. Below you can see how to use this function to extract data for analysis:

 SELECT p.code, p.title, p.ss_bonds, p.ssbonds_overlap, p.intra_count, p.sci_name_src, p.len, p.tax_path, p.pfam_families, p.src_class, ( SELECT s.id FROM src_classes s WHERE s.src_class::text = p.src_class::text) AS src_class_id, p.len_class7, ( SELECT s.val FROM sources_organela s WHERE s.code = p.code::bpchar AND s.tag::text = 'EXPRESSION_SYSTEM_CELLULAR_LOCATION'::text) AS expression_system_cellular_location, ( SELECT s.val FROM sources_organela s WHERE s.code = p.code::bpchar AND s.tag::text = 'CELLULAR_LOCATION'::text) AS cellular_location, ps.sequence, ps.uniprot_code, ps.accession_code, ps.cc, ps.seq_uniprot, ps.chain_id FROM proteins p JOIN nr n ON n.code::text = p.code::text AND n.rep7 = true JOIN ps ps ON ps.code::text = n.code::text AND ps.chain_id = n.chain_id AND ps.het = false WHERE p.is_excluded = false AND p.chain_cnt = 1 AND p.is_set7 = true AND p.reactive_cnt7 = 0 ORDER BY p.code;

An example result with corrected titles and some manually added columns is shown below.

PostgreSQL كوسيط معالجة

في هذا العمل ، أوضحنا كيفية معالجة البيانات ، من الجلب إلى التحليل. عند العمل بالبيانات العلمية ، يلزم أحيانًا التطبيع ، وأحيانًا لا. عند العمل بكميات صغيرة من البيانات التي لن يتم إعادة استخدامها لتحليل آخر ، يكفي تركها بدون تسوية حيث تكون المعالجة سريعة بما فيه الكفاية.

السبب وراء القيام بذلك كله في قاعدة بيانات واحدة للمعلومات الحيوية هو أن PostgreSQL قادرة على دمج العديد من اللغات. يتضمن ذلك R ، الذي يمكنه إجراء تحليل إحصائي مباشرة في قاعدة البيانات - موضوع مقال مستقبلي حول أدوات المعلوماتية الحيوية.

شكر خاص لزملائه في Toptal Stefan Fuchs و Aldo Zelen على استشاراتهم القيمة.