1. أصول اختيار أنواع البيانات الدقيقة (Data Types Optimization)
إن أحد أكبر مسببات بطء قواعد بيانات أكسس وتضخم حجمها واستهلاكها لحد الـ 2GB هو الاستخدام العشوائي لأنواع الحقول، مثل اختيار نوع Long Text (مذكرة) لحقول لا تتجاوز بضع كلمات، أو استخدام Double لتخزين أعداد صحيحة صغيرة!
| نوع البيانات في أكسس | الحجم التخزيني | النطاق والاستخدام الأمثل | أخطاء شائعة يجب تفاديها |
|---|---|---|---|
| Short Text (نص مختصر) | حتى 255 حرفاً (حسب الطول الفعلي) | الأسماء، العناوين، أرقام الهواتف، الأكواد | ترك حجم الحقل (Field Size) عند 255 افتراضياً لأرقام الهواتف أو الرموز القصيرة. |
| Number: Long Integer | 4 بايت (32-bit) | المفاتيح الأجنبية المرتبطة بـ AutoNumber | استخدام نوع Integer أو Byte كمفتاح أجنبي لجدول مفتاحه الأساسي ترقيم تلقائي! |
| Currency (عملة) | 8 بايت (دقة ثابتة 4 خانات عشرية) | الأسعار، الإجماليات، الرواتب، الضرائب | استخدام Single أو Double في الحسابات المالية مما يسبب أخطاء الفاصلة العائمة (Rounding Drift). |
| Date/Time Extended | بايتات متغيرة بدقة نانو ثانية | السجلات الزمنية الحساسة والربط مع SQL Server | استخدامه عندما يكفي التاريخ العادي Date/Time. |
2. فلسفة المفاتيح: المفتاح الأساسي، الأجنبي، والمفتاح المركب
المفتاح الأساسي (Primary Key - PK) هو المعرف الفريد المطلق لكل سجل، ولا يجوز أن يقبل قيمة فارغة (Null) أو قيمة مكررة. المفتاح الأجنبي (Foreign Key - FK) هو حقل في جدول ثانوي يشير إلى المفتاح الأساسي في الجدول الرئيسي لبناء العلاقة.
يفضل دائماً في أنظمة أكسس اعتماد حقل ترقيم تلقائي
ID AutoNumber كمفتاح أساسي اصطناعي، حتى لو كان الكيان يمتلك معرفاً طبيعياً مثل (الرقم القومي، رقم الجواز، أو كود الصنف)؛ وذلك لضمان ثبات العلاقات البرمجية وسرعة الفهرسة حتى لو قررت الإدارة تغيير صيغة كود الصنف لاحقاً.
3. أنواع العلاقات الثلاث ومبدأ التكامل المرجعي الصارم
يدعم محرك مايكروسوفت أكسس ثلاثة أنماط رئيسية من العلاقات:
واحد لواحد (1 to 1)
سجل واحد في الجدول (أ) يقابله سجل واحد فقط في الجدول (ب). تُستخدم لعزل البيانات السرية (مثل البيانات الطبية للموظف) أو تقسيم الجداول شديدة العرض.
واحد لمتعدد (1 to Many)
عصب قواعد البيانات العلائقية؛ عميل واحد يمتلك عدة فواتير، مورد واحد يقدم عدة عروض، قسم واحد يضم عدة موظفين.
متعدد لمتعدد (Many to Many)
الطالب يسجل في عدة كورسات، والكورس يضم عدة طلاب. لا يمكن تمثيلها في جدولين ويجب فكها بجدول وصل وسيط.
هو صمام الأمان الذي يمنع وجود سجلات يتيمة (Orphan Records). عند تفعيله، لن يسمح لك أكسس بإدخال فاتورة لعميل غير مسجل برقم ID، ولن يسمح بحذف عميل ما زال مسجلاً له فواتير في النظام، إلا إذا فعلت تتالي الحذف (Cascade Delete).
4. هندسة جدول الوصل (Junction Table) لحل علاقات أطراف بأطراف
إذا حاولت تخزين أرقام المواد المسجلة للطالب في خلية واحدة مفصولة بفواصل، فأنت تدمر قواعد البيانات العلائقية! الحل الهندسي هو جدول وسيط:
-- جدول الطلاب
CREATE TABLE tbl_Students (
StudentID AUTOINCREMENT PRIMARY KEY,
StudentName VARCHAR(100) NOT NULL
);
-- جدول الكورسات
CREATE TABLE tbl_Courses (
CourseID AUTOINCREMENT PRIMARY KEY,
CourseTitle VARCHAR(100) NOT NULL,
CreditHours INTEGER DEFAULT 3
);
-- جدول الوصل الوسيط (Junction Table)
CREATE TABLE tbl_Student_Courses (
EnrollmentID AUTOINCREMENT,
StudentID INTEGER NOT NULL REFERENCES tbl_Students(StudentID),
CourseID INTEGER NOT NULL REFERENCES tbl_Courses(CourseID),
EnrollmentDate DATETIME,
Grade SINGLE,
CONSTRAINT PK_StudentCourse PRIMARY KEY (StudentID, CourseID) -- مفتاح مركب يمنع تكرار تسجيل نفس الكورس للطالب مرتين
);
محاكي ومدقق تطبيع البيانات والعلاقات (Access Normalization & Relationship Simulator)
استكشف كيف يتحول جدول مبيعات فوضوي مليء بالتكرار والشذوذ إلى هيكلية علائقية نقية من المستوى الثالث (3NF). اضغط على المراحل أدناه لمعاينة تفكيك الجداول ومعدل التكرار المحذوف.