MS SQL Server
قاعدة بيانات شائعة في بيئات مايكروسوفت المؤسسية. كثير من الأنظمة الداخلية والتقارير تعتمد عليها.
قاعدة بيانات شائعة في بيئات مايكروسوفت المؤسسية. كثير من الأنظمة الداخلية والتقارير تعتمد عليها.
ماذا يحمل MS SQL Server، ولماذا يهمّ ذلك هنا
في المؤسسات التي تعمل ضمن بيئة مايكروسوفت، هذه القاعدة غالباً تحمل أنظمة داخلية بُنيت على مدى سنوات، وبياناتها هي المرجع في مسائل تشغيلية كثيرة.
ومشكلة الوصول هي نفسها: البيانات موجودة والاستعلام يحتاج مهارة، فيتحول السؤال البسيط إلى طلب في طابور.
والقواعد نفسها تنطبق: قراءة فقط، ونطاق صريح، وحساب خدمة منفصل، وترجمة المخرَج إلى لغة مفهومة بدل عرض صفوف كما هي.
- بيانات أنظمة الأعمال — ما تسجّله التطبيقات المبنية فوقها.
- السجلات التاريخية — وكثيراً ما تكون المكان الوحيد الذي بقيت فيه البيانات القديمة.
- البيانات المرجعية — القوائم الرئيسية التي تعتمد عليها أنظمة أخرى.
- العروض والإجراءات المخزّنة — الوصول المنتقى الذي بناه فريقكم مسبقاً.
- هياكل التقارير — الأشكال المصممة للتحليل.
أسئلة يجيب عنها إلبي من SQL Server
ما حالة هذا السجل؟
من مخطط التقارير، بجملة مفهومة لا بصف خام.
كم عدد كذا؟
إحصاء ضمن النطاق المسموح.
متى حدث هذا؟
التاريخ المسجّل كما هو.
ما آخر قيمة مسجّلة؟
الحقل المحدد ضمن النطاق.
هل هذا موجود؟
بحث ضمن النطاق المسموح.
من المسؤول؟
الحقل المسجّل حيث يكون عرضه مناسباً.
كيف يقرأ إلبي من SQL Server
- تسجيل دخول أو مستخدم مُحتوىيبدأ الوصول إما بتسجيل دخول (login) على مستوى الخادم مربوط بمستخدم في قاعدة واحدة، وإما بمستخدم قاعدة مُحتوى (contained user) يتحقق من هويته عند القاعدة نفسها بلا تسجيل دخول على الخادم أصلاً. وفي الحالتين يُنشأ لهذا الربط ولا يستخدمه غيره.
- SELECT على مخطط للتقاريريُمنح المستخدم SELECT على مخطط لا يضم إلا العروض المتفق عليها للمساعد — GRANT SELECT ON SCHEMA::reporting مثلاً — ولا ينتمي إلى أي دور ثابت من أدوار القاعدة. ويُستبعد db_datareader لأنه يستطيع قراءة كل جدول في القاعدة.
- سلسلة الملكية تتكفل بالباقيحين يكون للعروض والجداول التي تحتها المالك نفسه، يتحقق SQL Server من الصلاحية على العرض وحده (ownership chaining)، فيقرأ المستخدم عبر العرض دون أي حق على الجداول. والعروض والإجراءات المخزّنة التي بناها فريقكم للتقارير تعمل بالطريقة نفسها.
- استدعاءات بمعاملات لا SQL مؤلَّفكل سؤال يقابله استعلام بمعاملات على عرض، أو إجراء مخزّن يُسمح للمستخدم بتنفيذه (EXECUTE). وما يقدمه السائل يدخل معاملاً؛ المساعد لا يكتب SQL من عنده.
- نسخة ثانوية قابلة للقراءة حيث توجدفي مجموعة توافر Always On مُعدّ فيها التوجيه للقراءة فقط، يُرسَل الاتصال الذي يعلن ApplicationIntent=ReadOnly إلى نسخة ثانوية قابلة للقراءة، فتبقى الاستعلامات بعيدة عن النسخة الرئيسية التي تخدم التطبيق.
- نتائج مصاغة للناسالرموز وأعلام البت وقيم التاريخ والوقت تعود جملاً بالعربية أو الإنجليزية، من غير المفاتيح الداخلية، والأسماء كما هي في سجلاتكم.
تسجيلات الدخول والمستخدمون وما يبقى ملككم
الوصول قراءة فقط: SELECT على مخطط واحد من العروض، وEXECUTE على ما يُتفق عليه من إجراءات للقراءة فقط، ولا عضوية في db_datareader أو db_owner أو أي دور يملك الكتابة.
والمخطط يحدد ما يستطيع المستخدم قراءته، وهوية السائل تحدد ما يُقال له. ويستطيع أمان مستوى الصفوف في SQL Server نفسه أن يفرض حدود كل عميل داخل القاعدة أيضاً.
وبيانات الاعتماد تسجيل دخول أو مستخدم مُحتوى تنشئونه، بكلمة مرور تضبطونها أو بحساب خدمة تتحكمون فيه. وتعطيل تسجيل الدخول أو حذف المستخدم ينهي الوصول من جهتكم دون تدخل منا.
وما يعيده الاستعلام يُستخدم للجواب الذي نُفّذ من أجله. ويُتلف محتوى الرسائل خلال 24 ساعة، في الغالب حين تنتهي المحادثة، ولا يصل إلى أي خدمة ذكاء اصطناعي خارجية.
ويستطيع SQL Server Audit تسجيل عمليات SELECT وEXECUTE التي يجريها هذا المستخدم على مخطط التقارير، في ملف أو في سجل أحداث Windows الذي يتحكم فيه فريقكم.
وإن تعذّر الوصول إلى الخادم أو النسخة الثانوية، أو عُطّل تسجيل الدخول، أو انتهت مهلة استعلام، يقول المساعد إنه لم يصل إلى الجواب ويحوّل إلى موظف، دون أن يقدم شيئاً قديماً بدلاً منه.
ما الذي يحلّ محلّه ربط SQL Server
ما يحلّ محلّه هذا هو التقارير التي تُطلب مراراً للإجابة عن سؤال واحد. كثير من التقارير في المؤسسات وُلدت من سؤال متكرر، ثم أصبحت ملفاً يُرسل أسبوعياً ولا يقرأه أحد.
والسبب أن التقرير يجيب عن سؤال عام بينما الناس يسألون أسئلة محددة. فيبقى الطلب على الاستعلام قائماً رغم وجود التقرير.
والاتصال يجيب عن السؤال المحدد لحظة طرحه، وهذا يقلّل التقارير ويقلّل الطلبات معاً.
أين توفّر استعلامات SQL Server أكثر الوقت
بيئات مايكروسوفت
أشهر موضع لهذه القاعدة.
الأنظمة الداخلية
بيانات بلا واجهة سهلة.
التقنية
تقليل طلبات الاستعلام.
العمليات
أرقام يومية دون انتظار.
المالية
أرقام مسجّلة بصلاحية محددة.
الإدارة
رقم واحد من دون دورة تقرير كاملة.
كيف تستفيدون فعلاً من SQL Server
ابدأوا من طلبات التقارير. في بيئات SQL Server كثير منها معلومة واحدة في ثوب تقرير — حالة طلب، أو عدد الشهر الماضي — وكل واحدة منها مرشحة لعرض واحد. وعدّها لبضعة أسابيع يبيّن بأيها تبدؤون.
وتحققوا من طريقة تخزين العربية. العربية المحفوظة في أعمدة varchar تحت ترتيب (collation) غير عربي تعود علامات استفهام، بينما تحفظها أعمدة nvarchar سليمة. والتأكد من ذلك في الجداول التي خلف كل عرض قبل الإطلاق هو ما يحسم هل تُقرأ الأسماء والعناوين صحيحة.
وانظروا في خطط التنفيذ قبل الإطلاق. الاستعلامات صغيرة، لكنها حين لا توجد نسخة ثانوية تتقاسم النسخة الرئيسية مع التطبيق؛ وغياب فهرس على مفتاح البحث هو السبب المعتاد لبطء استعلام صغير، وهو أمر يتحقق منه مسؤول قواعد البيانات بسرعة.
ما الذي يتطلبه ربط SQL Server
- مطابقة الأسئلة بالكائناتطابقوا كل سؤال متكرر بعرض أو إجراء قائم حيث يصلح، وبعرض جديد حيث لا يوجد.
- إنشاء مخطط للتقاريرضعوا العروض المتفق عليها في مخطط خاص بها، يملكه المالك نفسه للجداول الأصلية حتى تنطبق سلسلة الملكية.
- إنشاء تسجيل الدخول أو المستخدم المُحتوىأنشئوا الكيان، وامنحوه SELECT على المخطط وEXECUTE على الإجراءات المتفق عليها، ثم تأكدوا من صلاحياته الفعلية أنه لا يملك شيئاً آخر.
- توجيه القراءة إلى نسخة ثانويةإن كانت لديكم مجموعة توافر فيها نسخة ثانوية قابلة للقراءة، فأعدّوا التوجيه للقراءة فقط واجعلوا الاتصال يعلن نية القراءة. والنسخة الثانوية القابلة للقراءة تُرخّص بطريقة تختلف عن الخاملة، فتأكدوا من الوضع مع المسؤول عن تراخيص SQL Server لديكم.
- تفعيل التدقيقعرّفوا مواصفة تدقيق على مستوى القاعدة (database audit specification) لعمليات SELECT وEXECUTE التي يجريها المستخدم على مخطط التقارير، ليوجد السجل من أول استعلام.
- الاختبار ثم الإطلاق المحدودجرّبوا مرجعاً غير موجود، وسجل عميل آخر، واستعلاماً قد يمسح جدولاً كبيراً، ثم ابدؤوا بالعروض القليلة التي تجيب عن أكثر الأسئلة تكراراً.
البيانات الشخصية والتدقيق في SQL Server
قواعد بيانات أنظمة الأعمال على SQL Server تحفظ البيانات الشخصية مع كل شيء آخر — سجلات الموظفين أو العملاء أو المرضى أو الرواتب، بحسب التطبيق. وبموجب نظام حماية البيانات الشخصية في المملكة، مخطط التقارير هو موضع تقليل البيانات: الأعمدة التي لا يحتاجها السؤال تبقى خارج العرض، ويستطيع إخفاء البيانات الديناميكي (dynamic data masking) حجب الحقول الحساسة عن مستخدم لا يحتاج رؤيتها كاملة.
وموقع البيانات يتبع الخادم: مركز بياناتكم، أو مزوّد استضافة، أو خدمة SQL مُدارة في منطقة اخترتموها. والربط لا ينقل البيانات إلى أي مكان؛ دوّنوا الموقع بجانب تعريف المخطط.
ويعطي SQL Server Audit وقائمة صلاحيات المخطط المراجعَ الجوابين اللذين يحتاجهما — ما كان المستخدم يستطيع قراءته وما قرأه فعلاً — من أنظمتكم أنتم.
كيف يُجاب عن أسئلة SQL Server في أماكن أخرى
الجواب التقليدي تقرير: SQL Server Reporting Services، أو أداة ذكاء أعمال مبنية على البيانات نفسها. وهذا يناسب الاحتياجات المتكررة المنظمة، ويتوقف على من يبني كل تقرير ويصونه.
وMicrosoft تضيف ميزات Copilot إلى أدوات SQL لديها وإلى Azure SQL، موجّهة أساساً إلى من يكتب الاستعلامات ويضبطها أصلاً. فهي تسرّع الفنيين أكثر مما تعطي غيرهم إجابات مباشرة.
والجداول الحسابية المتصلة بالقاعدة اتصالاً حياً شائعة وخطرها صامت: تفاصيل الاتصال تنتقل مع الملف، وكذلك البيانات.
والخطأ المتكرر إضافة الحساب إلى db_datareader لأن العروض لم تكن جاهزة بعد. ومن تلك اللحظة يستطيع قراءة كل جدول في القاعدة، بما فيها ما لم يقصد أحد كشفه.
ما الذي تراه المؤسسات عادة
أسئلة متكررة عن ربط SQL Server
لا. المستخدم لا يملك غير SELECT على مخطط العروض، ولا ينتمي إلى db_datareader أو أي دور يكتب.
لا. النطاق صريح، ونوصي بطبقة عرض تحدّد ما يُقرأ بدقة.
الوصول يخضع لضوابط شبكتكم، وهذا جزء من التصميم يُحسم مع فريق تقنية المعلومات قبل الإطلاق.
الحمل يُقاس في الاختبار على بياناتكم قبل الإطلاق. الاستعلامات محدودة النطاق بحكم التصميم.
ما تسمحون به فقط. الأعمدة الحساسة تبقى خارج مخطط التقارير، ويمكن لإخفاء البيانات الديناميكي أن يحجب ما يلزم حجبه.
بإيقاف حساب الخدمة المنفصل.