التصميم: عملية تصميم قاعدة البيانات
تغطي هذه الوحدة عملية تصميم قاعدة البيانات، بدءاً من النمذجة المنطقية والتطبيع (Normalization) وصولاً إلى تحويل مخططات الكيانات والعلاقات (E-R) إلى جداول، وتصميم قواعد البيانات المادية وتنظيم الملفات.
Design: Database Design Process
This module covers the database design process, starting from logical modeling and normalization, to transforming E-R diagrams into relations, and physical database design including file organizations.
أهداف التعلم
- فهم عملية قاعدة البيانات ومخرجاتها.
- تطبيق التطبيع (Normalization) وفهم أدواره.
- تحويل مخطط الكيانات والعلاقات (E-R) إلى نموذج قاعدة بيانات علائقية.
- فهم مفاهيم قاعدة البيانات المادية.
- Understand database process and its outcome.
- Apply normalization and its roles.
- Transform E-R diagram into relational database model.
- Understand physical database concepts.
1 عملية تصميم قاعدة البيانات
1 Database Design Process
عملية ذات شقين: منطقي يصف البيانات برمجياً، ومادي يحدد التخزين التقني.
A two-step process: logical modeling for data description and physical design for technical storage specifications.
تتكون خطوات تصميم قواعد البيانات والملفات من:
- تطوير نموذج قاعدة بيانات منطقي (Logical database model) والذي يهتم بوصف البيانات باستخدام تدوين يتوافق مع تنظيم البيانات المستخدم بواسطة نظام إدارة قواعد البيانات (DBMS) مثل SQL Server.
- تطوير تصميم قاعدة بيانات مادي (Physical database design) والذي يهتم بتحديد المواصفات الفنية لقواعد البيانات وملفات الكمبيوتر.
يمكن إجراء كلا التصميمين بالتوازي.
Steps of designing database and files are:
- Developing a logical database model, which concerns describing data using a notation that corresponds to a data organization used by a DBMS such as SQL Server.
- Developing a physical database design, which concerns prescribing the technical specifications for databases and computer files.
Both designs can be conducted in parallel.
تبدأ أنشطة نمذجة وتصميم قواعد البيانات في مرحلة التخطيط وتستمر في التطور خلال جميع مراحل دورة حياة تطوير النظم (SDLC).
يتم استخدام التطبيع (Normalization) لوضع اللمسات الأخيرة على قاعدة البيانات المنطقية خلال مرحلة التصميم.
يتم دمج البيانات المطبّعة من جميع واجهات المستخدم لتشكيل نموذج قاعدة بيانات منطقي موحد.
Database modeling and design activities start at the planning phase and continue to evolve during all phases of the SDLC.
Normalization is the process used to finalize the logical database during the design phase.
Normalized data are combined from all user interfaces to constitute one consolidated logical database model, which is then compared with the translated E-R data model.
| Logical Database Model | Physical Database Design | |
|---|---|---|
| التركيز الأساسيPrimary Focus | وصف البيانات باستخدام تدوين برمجي (مثل الجداول والعلاقات)Describing data using DBMS notation (tables, relations) | المواصفات الفنية للتخزين وملفات الكمبيوترTechnical specifications for storage and computer files |
| العمليات الرئيسيةKey Processes | التطبيع (Normalization)، دمج العلاقاتNormalization, Merging relations | اختيار أنواع البيانات، تنظيم الملفات، ضوابط السلامةChoosing data types, File organization, Integrity controls |
لماذا يمكن إجراء التصميم المنطقي والمادي بالتوازي؟ Why can logical and physical database designs be conducted in parallel?
لأن التصميم المنطقي يركز على هيكلة البيانات وعلاقاتها بناءً على متطلبات العمل، بينما يركز التصميم المادي على كيفية تخزين هذه الهياكل بكفاءة على الأجهزة، وكلاهما يغذي الآخر.
Because logical design focuses on data structure and relationships based on business requirements, while physical design focuses on how to efficiently store these structures on hardware. They inform each other.
2 نموذج قاعدة البيانات العلائقية
2 Relational Database Model
جدول ثنائي الأبعاد يتكون من صفوف (سجلات) وأعمدة (سمات).
A two-dimensional table of data consisting of rows (records) and columns (attributes).
نموذج قاعدة البيانات العلائقية هو الأكثر استخداماً اليوم لأنظمة المعلومات الجديدة.
العلاقة (Relation) هي جدول بيانات ثنائي الأبعاد. تتكون كل علاقة من مجموعة من الأعمدة وعدد عشوائي من الصفوف.
يتوافق كل عمود في العلاقة مع سمة (Attribute) لتلك العلاقة، ويتوافق كل صف مع سجل (Record) يحتوي على قيم بيانات لكيان معين.
العلاقة جيدة الهيكلة (Well-structured relation) تحتوي على الحد الأدنى من التكرار وتسمح بإدراج وتعديل وحذف الصفوف دون أخطاء أو تناقضات.
The Relational database model is used very often today for new information systems.
A relation is a two-dimensional table of data. Each relation consists of a set of columns and an arbitrary number of rows.
Each column corresponds to an attribute, and each row corresponds to a record that contains data values for an entity.
A well-structured relation contains a minimum amount of redundancy and allows insertion, modification, and deletion of rows without errors or inconsistencies.
خصائص العلاقات تشمل: الإدخالات في الخلايا يجب أن تكون بسيطة (قيمة واحدة)، الإدخالات في أي عمود يجب أن تكون من نفس مجموعة القيم، كل صف فريد من خلال الحفاظ على قيمة مفتاح أساسي غير فارغة، يمكن تبديل تسلسل الأعمدة أو الصفوف دون تغيير معنى العلاقة.
Properties of relations include: Entries in cells should be simple (single value), entries in any column should be from the same set of values, each row is unique by preserving a non-empty primary key value, and the sequence of columns or rows can be interchanged without changing the meaning or use of the relation.
ماذا يحدث إذا لم تكن العلاقة جيدة الهيكلة؟ What happens if a relation is not well-structured?
ستعاني من التكرار (Redundancy) وأخطاء التعديل والإدراج والحذف (Anomalies)، مما يؤدي إلى عدم اتساق البيانات.
It will suffer from data redundancy and insertion, modification, and deletion anomalies, leading to data inconsistency.
3 التطبيع والاعتمادية الوظيفية
3 Normalization and Functional Dependency
التطبيع هو قواعد لتصميم جداول خالية من التكرار، والاعتمادية الوظيفية تعني أن قيمة سمة تحدد قيمة سمة أخرى.
Normalization defines rules for well-structured relations. Functional dependency means one attribute's value determines another's.
التطبيع (Normalization) يحدد القواعد والعملية لتصميم علاقات جيدة الهيكلة.
يعتمد التطبيع بشكل أساسي على مفهوم الاعتمادية الوظيفية (Functional Dependency)، وهي قيد بين سمتين حيث يتم تحديد قيمة سمة واحدة بواسطة قيمة سمة أخرى.
على سبيل المثال: Emp_ID → Name تعني أنه يمكننا الحصول على اسم الموظف بمعرفة معرفه.
يمكن أن تعتمد السمة وظيفياً على أكثر من سمة واحدة (مفتاح مركب).
Normalization defines the rules and a process for designing well-structured relations.
It relies heavily on Functional Dependency, which is a constraint between two attributes in which the value of one attribute is determined by the value of another attribute.
Example: Emp_ID → Name means we can get the employee's name by knowing their ID.
An attribute can also be functionally dependent on more than one attribute (composite key).
تطبيق عملية التطبيع يضمن أن كل سمة ليست مفتاحاً أساسياً ستعتمد فقط على المفتاح الأساسي بأكمله.
هذا يزيل التكرار ويحمي قاعدة البيانات من التناقضات عند تحديث البيانات.
Applying the normalization process assures that every nonprimary key attribute will depend upon ONLY the whole primary key.
This eliminates redundancy and protects the database from anomalies during data updates.
هل يمكن أن تكون الاعتمادية الوظيفية متبادلة بين سمتين؟ Can functional dependency be mutual between two attributes?
نعم، إذا كانت كلتا السمتين فريدتين (مثل رقم الهوية ورقم الجواز)، فكل منهما يحدد الآخر وظيفياً (علاقة 1:1).
Yes, if both attributes are unique identifiers (like National ID and Passport Number), they functionally determine each other (1:1 relationship).
4 الصيغة الطبيعية الثانية (2NF)
4 Second Normal Form (2NF)
كل سمة غير أساسية تعتمد على المفتاح الأساسي بالكامل (لا يوجد اعتماد جزئي).
Every non-primary key attribute is functionally dependent on the WHOLE primary key (no partial dependency).
تكون العلاقة في الصيغة الطبيعية الثانية (2NF) إذا كانت كل سمة غير أساسية تعتمد وظيفياً على المفتاح الأساسي بأكمله (وليس جزءاً منه).
تتحقق 2NF إذا توفر أي من الشروط التالية:
- يتكون المفتاح الأساسي من سمة واحدة فقط.
- لا توجد سمات غير أساسية في العلاقة.
- كل سمة غير أساسية تعتمد وظيفياً على المجموعة الكاملة لسمات المفتاح الأساسي.
A relation is in 2NF if every nonprimary key attribute is functionally dependent on the whole (not part of) primary key.
A relation is automatically in 2NF if any of the following conditions is achieved:
- The primary key consists of only one attribute.
- No nonprimary key attributes exist in the relation.
- Every nonprimary key attribute is functionally dependent on the full set of primary key attributes.
لتحويل علاقة إلى 2NF، يجب تفكيكها (Decompose) إلى علاقات جديدة باستخدام السمات التي تحدد سمات أخرى.
على سبيل المثال، إذا كان لدينا مفتاح مركب (Emp_ID, Course) وكانت سمة Name تعتمد فقط على Emp_ID، فهذا خرق لـ 2NF ويجب فصل بيانات الموظف في جدول مستقل.
To convert a relation to 2NF, decompose it into new relations using the attributes that determine other attributes.
For example, if a composite key is (Emp_ID, Course) and the attribute 'Name' depends only on 'Emp_ID', this violates 2NF (partial dependency) and employee data must be separated into its own table.
إذا كان الجدول يحتوي على مفتاح أساسي مكون من عمود واحد، هل يمكن أن يخرق قاعدة 2NF؟ If a table has a single-column primary key, can it violate 2NF?
لا، إذا كان المفتاح الأساسي عموداً واحداً، فالجدول تلقائياً في 2NF لأنه لا يمكن أن يكون هناك اعتماد جزئي على مفتاح غير مركب.
No, if the primary key is a single column, the table is automatically in 2NF because partial dependency on a non-composite key is impossible.
5 الصيغة الطبيعية الثالثة (3NF)
5 Third Normal Form (3NF)
الجدول في 2NF ولا توجد سمات غير أساسية تعتمد على سمات غير أساسية أخرى (لا يوجد اعتماد متعدي).
The relation is in 2NF and has no transitive dependencies (non-key attributes depending on other non-key attributes).
تكون العلاقة في الصيغة الطبيعية الثالثة (3NF) إذا تحققت الشروط التالية:
- العلاقة موجودة في 2NF.
- لا توجد اعتمادات وظيفية بين أكثر من سمة غير أساسية (أي لا يوجد اعتماد متعدي - Transitive Dependency).
لتحويل علاقة إلى 3NF، يتم تفكيكها إلى علاقات جديدة لفصل السمات المعتمدة على بعضها.
A relation is in the 3NF if the following conditions are satisfied:
- The relation is in the 2NF.
- No functional dependencies exist between more than one nonprimary key attributes (i.e., no transitive dependency).
To convert a relation to 3NF, decompose it into new relations using the attributes that determine other attributes.
مثال: في جدول المبيعات SALES(Customer_ID, Customer_Name, Salesperson, Region)، إذا كان Customer_ID يحدد Salesperson، و Salesperson يحدد Region، فإن Region تعتمد بشكل متعدٍ على Customer_ID.
الحل هو فصل Salesperson و Region في جدول مستقل SPERSON(Salesperson, Region).
Example: In a SALES relation (Customer_ID, Customer_Name, Salesperson, Region), if Customer_ID determines Salesperson, and Salesperson determines Region, then Region is transitively dependent on Customer_ID.
The solution is to decompose into SALES1(Customer_ID, Customer_Name, Salesperson) and SPERSON(Salesperson, Region).
لماذا نعتبر الاعتماد المتعدي مشكلة؟ Why is transitive dependency considered a problem?
لأنه يسبب تكراراً للبيانات. إذا تغيرت منطقة مندوب المبيعات، سنضطر لتحديثها في كل صف يظهر فيه هذا المندوب، مما قد يؤدي إلى عدم اتساق البيانات.
Because it causes data redundancy. If a salesperson's region changes, we would have to update it in every row that salesperson appears, risking update anomalies.
6 تحويل مخطط E-R إلى علاقات
6 Transforming E-R Diagram into Relations
تحويل الكيانات إلى جداول، والعلاقات إلى مفاتيح أجنبية أو جداول وسيطة، ثم دمجها.
Converting entities to tables, relationships to foreign keys or associative tables, and merging them.
هناك أربع خطوات رئيسية لتحويل مخطط E-R إلى تدوين علائقي:
- تمثيل الكيانات (Represent entities): إنشاء علاقة لكل نوع كيان، حيث يصبح المعرف هو المفتاح الأساسي.
- تمثيل العلاقات (Represent relationships): يعتمد على درجة العلاقة وعددها (Cardinalities).
- تطبيع العلاقات (Normalize): إزالة التكرار الذي قد يظهر.
- دمج العلاقات (Merge): دمج العلاقات المطبّعة من مصادر مختلفة (مثل واجهات المستخدم ومخططات E-R) لإزالة التكرار وإعادة التطبيع.
There are four main steps to transform an E-R diagram into relational notation:
- Represent entities: Make a relation for each entity type. The identifier becomes the primary key.
- Represent relationships: Depends on the degree and cardinalities of the relationship.
- Normalize the relations: Remove redundancy that might have appeared.
- Merge the relations: Bottom-up normalization of user views and transforming E-R diagrams into sets of relations should be merged and renormalized to remove redundancy.
عند تمثيل الكيانات، يجب أن يحدد المفتاح الأساسي كل صف بشكل فريد وأن يكون غير متكرر.
عند دمج العلاقات، قد نجد أن مخطط E-R أنتج جدولاً EMPLOYEE1(Emp_ID, Name, Address, Phone) وواجهة المستخدم أنتجت EMPLOYEE2(Emp_ID, Name, Address, Jobcode).
الدمج ينتج جدولاً واحداً شاملاً بدون تكرار.
When representing entities, the primary key must uniquely identify every row and be nonredundant.
When merging relations, an E-R diagram might yield EMPLOYEE1(Emp_ID, Name, Address, Phone) while a user interface yields EMPLOYEE2(Emp_ID, Name, Address, Jobcode).
Merging them creates a single comprehensive relation without redundancy.
كيف يتم تمثيل علاقة متعدد إلى متعدد (M:N) في قاعدة البيانات العلائقية؟ How is a many-to-many (M:N) relationship represented in a relational database?
يتم إنشاء جدول جديد (كيان وسيط - Associative Entity) يحتوي على مفتاح مركب يتكون من المفاتيح الأساسية للكيانين المرتبطين.
A new relation (associative entity) is created with a composite primary key consisting of the primary keys of the related entities.
7 تصميم قاعدة البيانات المادية
7 Physical Files and Database Design
تحديد أنواع البيانات، الحقول، ضوابط السلامة، والجداول المادية لتخزين البيانات بكفاءة.
Defining data types, fields, integrity controls, and physical tables for efficient data storage.
يتطلب التصميم المادي معلومات مثل العلاقات المطبّعة، تقديرات الحجم، وتوقعات وقت الاستجابة.
يتم تبني نهج من أسفل إلى أعلى (Bottom-up) يشمل: تصميم الحقول (أصغر وحدة بيانات مثل الاسم الأول)، اختيار أنواع البيانات (مثل VARCHAR2, NUMBER, DATE في Oracle 10g)، التحكم في سلامة البيانات (Data Integrity)، وتصميم الجداول المادية لتحقيق الاستخدام الفعال للتخزين وسرعة المعالجة.
Physical design needs information like normalized relations, volume estimates, and response time expectations.
A bottom-up approach is adopted: Designing Fields (smallest units of application data), Choosing Data Types (coding schemes like VARCHAR2, NUMBER, DATE in Oracle 10g), Controlling Data Integrity, and Designing Physical Tables to achieve efficient secondary storage use and data processing speed.
طرق التحكم في سلامة البيانات تشمل: القيمة الافتراضية (Default value)، التحكم في النطاق (Range control)، السلامة المرجعية (Referential integrity)، والتحكم في القيم الفارغة (Null value control).
الجدول المادي قد لا يتوافق بالضرورة مع علاقة واحدة (قد يتم دمج جداول لتحسين الأداء).
Data integrity control methods include: Default value, Range control, Referential integrity, and Null value control.
A physical table is a named set of rows and columns that specifies the fields in each row. It may or may not correspond to exactly one logical relation (e.g., denormalization for performance).
لماذا قد يختلف الجدول المادي عن العلاقة المنطقية؟ Why might a physical table differ from a logical relation?
لأسباب تتعلق بالأداء؛ قد يقوم مصمم قاعدة البيانات بدمج جدولين منطقيين في جدول مادي واحد (Denormalization) لتقليل وقت الاستعلام.
For performance reasons; a database designer might combine two logical relations into one physical table (denormalization) to reduce query time.
8 تنظيم الملفات
8 File Organizations
طرق ترتيب صفوف الجدول في الذاكرة: تسلسلي، مفهرس، أو مجزأ (Hashed).
Methods of arranging table rows in memory: Sequential, Indexed, or Hashed.
ترتب أنظمة التشغيل الملفات بشكل مختلف. يجب على مصممي قواعد البيانات مراعاة أهداف كل ملف مثل: الاسترجاع السريع، الإنتاجية العالية، الحماية من الفشل، والأمان.
الأنواع الرئيسية لتنظيم الملفات هي:
- التسلسلي (Sequential): تخزين السجلات بشكل متتالٍ.
- المفهرس (Indexed): استخدام بنية شجرية أو فهرس للوصول السريع.
- المجزأ (Hashed): استخدام خوارزمية تجزئة لتحديد الموقع الفعلي للسجل بناءً على المفتاح.
Operating systems arrange files differently. Database designers should consider objectives like fast data retrieval, high throughput, protection from failures, and security.
Main file organization types are:
- Sequential: records are stored one after another.
- Indexed: uses an index structure for fast retrieval.
- Hashed: uses a hashing algorithm on the key to determine the relative record number.
التنظيم التسلسلي بطيء في البحث العشوائي ولكنه ممتاز للقراءة الشاملة.
التنظيم المفهرس يسرع البحث ولكنه يستهلك مساحة إضافية ويبطئ عمليات الإدراج.
التنظيم المجزأ يوفر أسرع وصول مباشر للسجلات الفردية ولكنه غير فعال لاستعلامات النطاق (Range queries).
Sequential organization is slow for random access but great for full scans.
Indexed organization speeds up searches but consumes extra space and slows down insertions.
Hashed organization provides the fastest direct access to individual records but is inefficient for range queries.
| Sequential | Indexed | Hashed | |
|---|---|---|---|
| آلية الوصولAccess Mechanism | مسح من البداية للنهايةScan from start to end | بحث عبر شجرة الفهرسSearch through index tree | حساب الموقع المباشر عبر خوارزميةDirect location calculation via algorithm |
أي تنظيم ملفات ستختاره لنظام يتطلب البحث عن موظف معين باستخدام رقم هويته بسرعة فائقة؟ Which file organization would you choose for a system that requires extremely fast retrieval of a specific employee by their ID?
التنظيم المجزأ (Hashed)، لأنه يوفر وصولاً مباشراً وفورياً باستخدام خوارزمية التجزئة على رقم الهوية.
Hashed organization, because it provides immediate direct access by applying a hashing algorithm to the ID.