نموذج البيانات الفيزيائي

قوة قاعدة البيانات تتناسب طرديًا مع قوة الأسئلة التي يمكنك طرحها عليها. —Hans Rosling

في هذا الفصل، نخطو الخطوة الأخيرة في تخطيط قاعدة بياناتنا: إنشاء نموذج البيانات الفيزيائي (physical data model). فكيف تحوّل نموذج بيانات منطقيًا إلى نموذج بيانات فيزيائي؟

يجب أن تكون قادرًا على شرح المصطلحات التالية، وكيفية تصوّر ذلك (حيثما كان ذا صلة)، وشرحه بمثال:

• نموذج البيانات الفيزيائي؛
• نوع البيانات (datatype)؛
• قيمة NULL.

مقدمة

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

وتجيب الطبقة الفيزيائية لنموذج بياناتنا عن السؤال: "كيف ينبغي أن نصف بنية البيانات وفق نظام إدارة قواعد البيانات (DBMS) الذي اخترناه؟" وعند فعل ذلك، نكمّل نموذج بياناتنا بالمعلومات التالية:

• نوع البيانات (datatype) للعمود
• طول القيمة
• ما إذا كانت القيمة يمكن أن تكون فارغة (NULL) أم لا
• (القيود) التي نريد فرضها على جدول معين (لا تُناقش في هذه الدورة)
• الفهرسة (لا تُناقش في هذه الدورة)
• العروض (لا تُناقش في هذه الدورة)
• الإجراءات (لا تُناقش في هذه الدورة)
• استخدام مساحة القرص (لا تُناقش في هذه الدورة)

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

والاختلافات صغيرة غالبًا، خصوصًا في أنظمة إدارة قواعد البيانات الخاصة بقواعد البيانات المهيكلة وفق نموذج قاعدة البيانات العلائقية، لأن معايير قد وُضعت. فقد لُخّصت المعايير الخاصة بنموذج قاعدة البيانات العلائقية في معيار ANSI الخاص بلغة SQL، أولًا في عام 1986 ثم في وقت أحدث في عام 2016. ويلتزم مطوّرو أنظمة إدارة قواعد البيانات العلائقية عادةً بهذه المعايير، وإن كانوا يضيفون أيضًا صيغهم الخاصة للتمييز بين منتجاتهم ومنتجات السوق الأخرى. والتركيز في هذه الدورة على PostgreSQL؛ كما لا نقارن مع أنظمة إدارة قواعد بيانات أخرى داخل هذه الدورة.

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

من النموذج المنطقي إلى النموذج الفيزيائي

في ترجمة نموذج بيانات منطقي إلى نموذج بيانات فيزيائي، وفي سياق هذه الدورة، سنضيف المعلومات التالية:

• تُسمّى الجداول والأعمدة وفقًا لاصطلاحات التسمية المتفق عليها؛ ولذلك يجب أن نحدد اصطلاحات التسمية أولًا؛
• نحدد نوع بيانات وطولًا لكل من الأعمدة؛
• نبيّن لكل من الأعمدة ما إذا كانت القيمة في العمود يمكن أن تكون فارغة (NULL) أم لا؛
• نفرض قيودًا (constraints) على جدول.

اصطلاحات التسمية

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

وهناك طرق مختلفة لوضع قواعد التسمية، وكل شركة ستستخدم قواعدها الخاصة. وبعض الأفكار:

• حالة الأحرف في الأسماء و/أو فصل الكلمات: UPPER CASE،
• الحروف الصغيرة (lower case)،
• camelCase،
• PascalCase،
• snake_case،
• kebab-case: الكلمات مفصولة.

استخدام صيغة الجمع أو المفرد (الجدول "players" أو "player") فصل الكلمات عن بعضها:

• بشرطة سفلية (_)،
• بنقطة،
• بحرف كبير،
• بمزيج مما سبق.

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

وإضافة إلى ذلك، يمكننا تقديم النصائح التالية:

• لا تستخدم المسافات؛
• لا تستخدم محارف أجنبية؛
• لا تستخدم الكلمات المفتاحية المحجوزة في SQL أو في نظام إدارة قواعد البيانات.

ونطبّق نحن اصطلاحات التسمية التالية:

• الجدول: نستخدم اسمًا في المفرد بحروف صغيرة. وتُفصل الكلمات المختلفة بـ "_".
• العمود: يُوصف اسم العمود بحروف صغيرة، مع فصل عدة كلمات بـ "_". وحاول أن تُبقي اسم العمود قصيرًا قدر الإمكان، ولكن بطريقة تجعل من الممكن مع ذلك معرفة ما يعنيه.
• المفتاح الأساسي: إن أمكن، نسمّي المفتاح "id". وبهذه الطريقة، يسهل دائمًا على المستخدمين تحديد المفتاح الأساسي.
• المفتاح الأجنبي: المفاتيح الأجنبية إشارات إلى جداول أخرى، لذا نحاول تضمين اسم الجدول الأصلي في الاسم. فمثلًا، يمكن تسمية المفتاح الأساسي "id" من جدول "lecturer" باسم "lecturer_id" في جداول أخرى بوصفه مفتاحًا أجنبيًا.

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

نوع البيانات

في نموذج البيانات الفيزيائي، سنحدد نوع البيانات لكل عمود. ونأخذ هنا في الاعتبار طبيعة البيانات التي نريد إضافتها. وفي الخطوات الأولى التي خطوتها مع SQL، داخل فصل "مقدمة إلى SQL"، تعرّفت بالفعل على أنواع البيانات الأكثر استخدامًا: char() وvarchar() وinteger وdate.

وإضافة إلى أنواع البيانات هذه، يقدّم PostgreSQL مجموعة واسعة من أنواع البيانات الإضافية. ولكل نوع بيانات دور معين، ويقدّم، من خلال استخدام الدوال، قدرات إضافية.

وعند تعريف نوع البيانات، يتعيّن عليك أحيانًا تحديد الطول. ويمكن أن يكون لأنواع البيانات طول ثابت (مثلًا integer 4 بايت، وboolean 1 بت، وreal 4 بايت...) أو طول متغير (مثل char وvarchar وnumeric...).

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

NULL أو NOT NULL

في التصميم الفيزيائي، نحتاج إلى تحديد ما إذا كانت القيمة في عمود يمكن أن تكون فارغة أم لا. وللأعمدة التي لا ينبغي أن تكون فارغة أبدًا، يمكننا تحديد NOT NULL. أما الأعمدة التي لم نحدد لها ذلك، فيمكن أن تكون قيمتها فارغة.

والاختيار الذي يجب اتخاذه هنا يستند إلى نموذج البيانات المنطقي، ويتحدد بعنصرين:

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

ويمكن أن تعني القيمة NULL أمرين: من جهة، يمكن أن تعني أنه قد تكون هناك قيمة مُدخلة، لكننا لا نعرف تلك القيمة. ويمكن عندئذ إدخال القيمة في وقت لاحق. ومن جهة أخرى، يمكن أن تشير NULL إلى أنه لا توجد في هذه الحالة بعينها قيمة ممكنة، فالعمود غير منطبق على هذا الكيان.

وإجراء مقارنة مع قيمة NULL يعطي قيمة NULL نتيجةً لذلك، لأن المقارنة مع شيء غير معروف تكون دائمًا غير معروفة.