مفاهيم نظام قواعد البيانات ومعماريته
تغطي هذه الوحدة نماذج البيانات، المخططات والحالات، معمارية المخططات الثلاثة، استقلالية البيانات، لغات واجهات أنظمة إدارة قواعد البيانات، وتصنيفاتها التاريخية والحديثة.
Database System Concepts and Architecture
This module covers data models, schemas and states, the three-schema architecture, data independence, DBMS languages and interfaces, and the classification of DBMSs.
أهداف التعلم
- شرح مفاهيم نظام قواعد البيانات الأساسية مثل نماذج البيانات والمخططات.
- التمييز بين مخطط قاعدة البيانات (Intension) وحالة قاعدة البيانات (Extension).
- فهم معمارية المخططات الثلاثة وكيفية تحقيقها لاستقلالية البيانات.
- التعرف على لغات أنظمة إدارة قواعد البيانات (DDL و DML) والواجهات المختلفة.
- مقارنة معماريات أنظمة إدارة قواعد البيانات (المركزية، ثنائية الطبقات، وثلاثية الطبقات).
- Explain basic database system concepts such as data models and schemas.
- Distinguish between database schema (intension) and database state (extension).
- Understand the Three-Schema Architecture and how it achieves data independence.
- Identify DBMS languages (DDL and DML) and various interfaces.
- Compare DBMS architectures (Centralized, 2-tier, and 3-tier).
1 نماذج البيانات (Data Models)
1 Data Models
مجموعة من المفاهيم التي تصف بنية قاعدة البيانات وعملياتها وقيودها، تشبه المخطط الهندسي للمبنى.
A set of concepts to describe the structure, operations, and constraints of a database, much like an architectural blueprint.
نموذج البيانات يحدد كيفية تنظيم البيانات. يتضمن:
- البنية (عناصر البيانات، الكيانات، العلاقات).
- القيود (لضمان صحة البيانات).
- العمليات (الأساسية مثل الإدراج والحذف، والمخصصة مثل حساب المعدل).
تنقسم النماذج إلى: مفاهيمية (عالية المستوى، قريبة من فهم المستخدم)، مادية (منخفضة المستوى، تصف تفاصيل التخزين)، وتنفيذية/تمثيلية (بين الاثنين، تستخدم في الأنظمة التجارية مثل النموذج العلائقي).
A data model defines how data is organized. It includes:
- Structure (data elements, entities, relationships).
- Constraints (to ensure valid data).
- Operations (basic like insert/delete, and user-defined like compute_gpa).
Categories include: Conceptual (high-level, close to user perception), Physical (low-level, details of storage), and Implementation/Representational (between the two, used by commercial DBMSs like relational models).
التقسيم إلى مستويات يسمح بفصل الاهتمامات.
النماذج المفاهيمية تركز على 'ماذا' نخزن (دلالات البيانات)، بينما النماذج المادية تركز على 'كيف' نخزنها (الأداء، الفهارس).
هذا الفصل هو الأساس لتحقيق استقلالية البيانات في الأنظمة الحديثة.
Categorizing models into levels allows separation of concerns.
Conceptual models focus on 'what' to store (semantics), while physical models focus on 'how' to store it (performance, indexes).
This separation is the foundation for achieving data independence in modern systems.
لماذا لا نستخدم النموذج المادي مباشرة لتصميم قاعدة البيانات؟ Why don't we use the physical data model directly to design a database?
لأنه معقد جداً ويرتبط بتفاصيل الأجهزة والتخزين، مما يجعل من الصعب على المستخدمين ومحللي الأعمال فهمه أو تعديله. النموذج المفاهيمي يوفر لغة مشتركة.
Because it is too complex and tied to hardware/storage details, making it difficult for users and business analysts to understand or modify. The conceptual model provides a common language.
2 مخطط قاعدة البيانات مقابل حالة قاعدة البيانات
2 Database Schema vs. Database State
المخطط هو الهيكل الثابت (النية)، بينما الحالة هي البيانات المتغيرة في لحظة معينة (الامتداد).
The schema is the static structure (intension), while the state is the changing data at a specific moment (extension).
مخطط قاعدة البيانات (Schema): هو وصف بنية قاعدة البيانات والقيود وأنواع البيانات. يتغير نادراً جداً ويسمى أيضاً (Intension).
حالة قاعدة البيانات (State): هي البيانات الفعلية المخزنة في لحظة زمنية معينة. تتغير مع كل عملية تحديث أو إدراج، وتسمى أيضاً (Extension) أو (Snapshot).
الحالة الابتدائية هي عند تحميل البيانات لأول مرة، والحالة الصالحة هي التي تلبي جميع قيود المخطط.
Database Schema: The description of the database structure, constraints, and data types. It changes very infrequently and is also called the Intension.
Database State: The actual data stored at a particular moment in time. It changes every time the database is updated, and is also called an instance, snapshot, or Extension.
The initial state is when data is first loaded, and a valid state satisfies all schema constraints.
التمييز بين المخطط والحالة ضروري لعمليات إدارة قواعد البيانات.
المترجمات (Compilers) تتعامل مع المخطط للتحقق من صحة الاستعلامات، بينما محرك التنفيذ يتعامل مع الحالة لاسترجاع البيانات.
تغيير المخطط يتطلب عملية مكلفة تسمى (Schema Evolution).
Distinguishing between schema and state is essential for DBMS operations.
Compilers use the schema to validate queries, while the execution engine interacts with the state to retrieve data.
Changing the schema requires an expensive operation known as Schema Evolution.
إذا قمت بإضافة عمود جديد لجدول، هل قمت بتغيير المخطط أم الحالة؟ If you add a new column to a table, did you change the schema or the state?
لقد قمت بتغيير المخطط (Schema) لأنك عدلت الهيكل الوصفي لقاعدة البيانات.
You changed the schema, because you modified the structural description of the database.
3 معمارية المخططات الثلاثة واستقلالية البيانات
3 Three-Schema Architecture and Data Independence
معمارية تفصل قاعدة البيانات إلى ثلاثة مستويات: داخلي (تخزين)، مفاهيمي (منطق)، وخارجي (عروض المستخدمين) لتحقيق استقلالية البيانات.
An architecture that separates the DB into three levels: Internal (storage), Conceptual (logic), and External (user views) to achieve data independence.
تم اقتراح هذه المعمارية لدعم استقلالية البيانات وتعدد العروض. تتكون من:
- المستوى الداخلي (Internal): يصف التخزين المادي ومسارات الوصول (الفهارس).
- المستوى المفاهيمي (Conceptual): يصف البنية والقيود لقاعدة البيانات بأكملها لمجتمع المستخدمين.
- المستوى الخارجي (External): يصف عروضاً مخصصة لمجموعات مختلفة من المستخدمين.
استقلالية البيانات تعني القدرة على تغيير مخطط في مستوى معين دون الحاجة لتغيير المخطط في المستوى الأعلى منه (استقلالية منطقية ومادية).
Proposed to support program-data independence and multiple views. It consists of:
- Internal schema: describes physical storage and access paths (indexes).
- Conceptual schema: describes the structure and constraints for the whole DB for a community of users.
- External schemas: describe various user views.
Data Independence is the capacity to change a schema at one level without changing the schema at the next higher level (Logical and Physical independence).
الاستقلالية المنطقية (تغيير المفاهيمي دون التأثير على الخارجي) أصعب بكثير من الاستقلالية المادية (تغيير الداخلي دون التأثير على المفاهيمي).
لأن التغييرات المنطقية قد تزيل بيانات تعتمد عليها التطبيقات، بينما التغييرات المادية عادة ما تكون لتحسين الأداء فقط (مثل إضافة فهرس).
Logical data independence (changing conceptual without affecting external) is much harder to achieve than physical data independence (changing internal without affecting conceptual).
Logical changes might remove data that applications rely on, whereas physical changes are usually just for performance optimization (like adding an index).
| Logical Data Independence | Physical Data Independence | |
|---|---|---|
| مستوى التغييرLevel of Change | تغيير المخطط المفاهيميChange Conceptual Schema | تغيير المخطط الداخليChange Internal Schema |
| التأثير على التطبيقاتImpact on Applications | لا تتأثر المخططات الخارجية والتطبيقاتExternal schemas and apps unchanged | لا يتأثر المخطط المفاهيميConceptual schema unchanged |
| صعوبة التحقيقDifficulty to Achieve | صعبة جداًVery difficult | أسهل نسبياًRelatively easier |
إذا قمنا بتغيير نوع محرك التخزين من HDD إلى SSD وإعادة تنظيم الملفات، أي نوع من الاستقلالية يحمي التطبيقات من التعطل؟ If we change the storage engine from HDD to SSD and reorganize files, which type of independence protects the applications from breaking?
استقلالية البيانات المادية (Physical Data Independence).
Physical Data Independence.
4 لغات أنظمة إدارة قواعد البيانات
4 DBMS Languages
لغة تعريف البيانات (DDL) لبناء الهيكل، ولغة معالجة البيانات (DML) للتعامل مع المحتوى (استرجاع وتحديث).
Data Definition Language (DDL) builds the structure, and Data Manipulation Language (DML) handles the content (retrieval and updates).
DDL (لغة تعريف البيانات): يستخدمها مدير قاعدة البيانات (DBA) والمصممون لتحديد المخطط المفاهيمي (وأحياناً الداخلي والخارجي). نظرياً يوجد VDL لتعريف العروض و SDL لتعريف التخزين، لكن عملياً تدمج في DDL.
DML (لغة معالجة البيانات): تستخدم للاسترجاع والتحديث. تنقسم إلى:
- عالية المستوى/تصريحية (مثل SQL): تحدد 'ماذا' نريد وليس 'كيف'، وتتعامل مع مجموعة سجلات.
- منخفضة المستوى/إجرائية: يجب تضمينها في لغة برمجة وتتعامل مع سجل واحد في كل مرة (تحتاج إلى حلقات تكرار).
DDL (Data Definition Language): Used by DBA and designers to specify the conceptual schema. Theoretically, VDL (views) and SDL (storage) exist, but practically they are integrated into DDL.
DML (Data Manipulation Language): Used for retrievals and updates. Types:
- High-Level/Declarative (e.g., SQL): specifies 'what' data to retrieve rather than 'how', set-oriented.
- Low-Level/Procedural: embedded in programming languages, record-at-a-time, requires looping constructs.
اللغات التصريحية (Declarative) تنقل عبء تحسين الاستعلام (Query Optimization) إلى نظام إدارة قواعد البيانات (DBMS)، مما يسهل عمل المبرمج.
بينما اللغات الإجرائية تتطلب من المبرمج كتابة خوارزمية البحث بنفسه، مما قد يؤدي إلى أداء ضعيف إذا لم يكن المبرمج خبيراً.
Declarative languages shift the burden of Query Optimization to the DBMS, simplifying the programmer's job.
Procedural languages require the programmer to write the search algorithm manually, which can lead to poor performance if the programmer lacks expertise.
| Active Data Dictionary | Passive Data Dictionary | |
|---|---|---|
| إمكانية الوصولAccessibility | يتم الوصول إليه بواسطة برامج DBMS والمستخدمينAccessed by DBMS software and users/DBA | يتم الوصول إليه بواسطة المستخدمين/DBA فقطAccessed by users/DBA only |
لماذا تعتبر SQL لغة تصريحية (Declarative) وليست إجرائية (Procedural)؟ Why is SQL considered a declarative language rather than procedural?
لأنك في SQL تكتب النتيجة التي تريدها (مثلاً SELECT * FROM Users) ولا تكتب خطوات كيفية جلب هذه البيانات من القرص الصلب خطوة بخطوة.
Because in SQL you specify the desired result (e.g., SELECT * FROM Users) without writing the step-by-step algorithm of how to fetch the data from the disk.
5 معماريات أنظمة إدارة قواعد البيانات
5 DBMS Architectures
تطورت من المركزية (جهاز واحد يفعل كل شيء) إلى ثنائية الطبقات (عميل وخادم) ثم ثلاثية الطبقات (إضافة خادم تطبيقات للويب والأمان).
Evolved from Centralized (one machine does all) to 2-tier (client and server) to 3-tier (adding an application server for web and security).
- المعمارية المركزية: يدمج كل شيء (البرامج، العتاد، واجهة المستخدم) في نظام كمبيوتر واحد.
- معمارية خادم-عميل ثنائية الطبقات (2-tier): العميل يتعامل مع واجهة المستخدم ويتصل مباشرة بخادم قاعدة البيانات (عبر ODBC/JDBC).
- معمارية ثلاثية الطبقات (3-tier): شائعة في تطبيقات الويب. تضيف طبقة وسيطة (خادم تطبيقات/ويب) بين العميل وقاعدة البيانات. العميل لا يتصل بقاعدة البيانات مباشرة، مما يعزز الأمان ويخزن منطق الأعمال (Business Logic) في الطبقة الوسيطة.
- Centralized Architecture: Combines everything (software, hardware, UI) into a single computer system.
- Two-Tier Client-Server: Client handles UI and connects directly to the DB server (via ODBC/JDBC).
- Three-Tier Architecture: Common for Web apps. Adds an intermediate layer (Application/Web Server) between client and DB. The client cannot access the DB directly, which enhances security and centralizes business logic.
المعمارية ثلاثية الطبقات تحل مشكلة 'العميل السمين' (Fat Client) في المعمارية الثنائية، حيث كان يجب تثبيت برامج تشغيل قواعد البيانات ومنطق الأعمال على كل جهاز عميل.
في الثلاثية، العميل يحتاج فقط إلى متصفح ويب (Thin Client).
The 3-tier architecture solves the 'Fat Client' problem of the 2-tier model, where DB drivers and business logic had to be installed on every client machine.
In 3-tier, the client only needs a web browser (Thin Client).
| 2-Tier Architecture | 3-Tier Architecture | |
|---|---|---|
| الطبقة الوسيطةMiddle Tier | غير موجودة (اتصال مباشر)None (Direct connection) | موجودة (خادم تطبيقات/ويب)Present (App/Web Server) |
| الأمانSecurity | أقل (العميل يصل للقاعدة مباشرة)Lower (Client accesses DB directly) | أعلى (العميل لا يصل للقاعدة مباشرة)Higher (Client cannot access DB directly) |
| حالة الاستخدام الشائعةCommon Use Case | تطبيقات سطح المكتب التقليديةTraditional Desktop Apps | تطبيقات الويبWeb Applications |
لماذا تعتبر المعمارية ثلاثية الطبقات أكثر أماناً من ثنائية الطبقات؟ Why is the 3-tier architecture considered more secure than the 2-tier?
لأن المستخدم (العميل) لا يمتلك وصولاً مباشراً لخادم قاعدة البيانات. خادم التطبيقات يعمل كجدار حماية ويدقق الطلبات قبل إرسالها لقاعدة البيانات.
Because the user (client) does not have direct access to the database server. The application server acts as a buffer/firewall, validating requests before sending them to the DB.
6 تاريخ نماذج البيانات
6 History of Data Models
تطورت النماذج من الشبكي والهرمي (معقدة وتعتمد على المؤشرات) إلى العلائقي (جداول بسيطة ومرنة) ثم الكائني والأنظمة الحديثة (NOSQL).
Models evolved from Network and Hierarchical (complex, pointer-based) to Relational (simple tables, flexible), then to Object-Oriented and NOSQL.
- النموذج الشبكي (Network): ظهر في الستينات (مثل نظام IDS). يمثل العلاقات المعقدة لكنه يعتمد على لغة ملاحية معقدة ومؤشرات متشابكة.
- النموذج الهرمي (Hierarchical): طورته IBM (نظام IMS). يخزن البيانات بشكل شجري، ممتاز للبيانات الهرمية لكنه سيء للعلاقات المتعددة.
- النموذج العلائقي (Relational): اقترحه E.F. Codd عام 1970. يستخدم الجداول (SQL) وهو المهيمن حالياً.
- النماذج الكائنية (Object-oriented): تدمج قواعد البيانات مع لغات البرمجة الكائنية (مثل C++).
- أنظمة البيانات الضخمة (NOSQL): مثل Key-value، Document، Graph، Column-based.
- Network Model: 1960s (e.g., IDS). Models complex relationships but uses navigational language and complex pointers.
- Hierarchical Model: IBM's IMS. Tree-like structure, good for hierarchies but bad for many-to-many relationships.
- Relational Model: Proposed by E.F. Codd (1970). Uses tables (SQL) and is currently dominant.
- Object-oriented Models: Seamless use with OOP languages (C++).
- Big Data (NOSQL): Key-value, Document, Graph, Column-based models.
السبب الرئيسي لانتصار النموذج العلائقي على الشبكي والهرمي هو 'الاستقلالية المنطقية للبيانات' واللغة التصريحية (SQL).
في النماذج القديمة، كان المبرمج يضطر لكتابة مسار التنقل (Navigation) عبر المؤشرات، مما يعني أن أي تغيير في هيكل البيانات يكسر جميع التطبيقات.
The main reason the Relational model defeated Network and Hierarchical is 'Logical Data Independence' and declarative language (SQL).
In older models, programmers had to write navigational paths via pointers, meaning any structural change broke all applications.
لماذا عادت بعض مفاهيم النماذج القديمة للظهور في قواعد بيانات NOSQL الحديثة (مثل Graph databases)؟ Why have some concepts from older models resurfaced in modern NOSQL databases (like Graph databases)?
لأن البيانات الحديثة (مثل الشبكات الاجتماعية) تحتوي على علاقات شديدة التعقيد يصعب معالجتها بكفاءة باستخدام الجداول العلائقية، مما جعل نموذج الرسم البياني (الشبيه بالنموذج الشبكي) أكثر كفاءة لهذه الحالات.
Because modern data (like social networks) has highly complex relationships that are inefficient to process using relational tables, making graph models (similar to the old network model) more efficient for these use cases.