#018 — Database Design | تصميم قواعد البيانات
أي نظام ناجح لا يعتمد فقط على كود جيد، بل يحتاج إلى بيانات منظمة ومصممة بشكل صحيح من البداية.
وهنا يأتي دور:
Database Design — تصميم قواعد البيانات
الفكرة ليست أن تنشئ Tables كثيرة، بل أن تسأل أولًا:
ما البيانات التي أحتاجها فعلًا؟ وكيف ترتبط ببعضها؟
لأن التصميم السيئ قد يؤدي إلى:
تكرار البيانات، صعوبة التعديل، أخطاء في العلاقات، بطء الاستعلامات، ومشاكل تظهر كلما كبر النظام.
لذلك نبدأ عادةً بـ:
Requirements → Entities → Attributes → Keys → Relationships → ERD → Database
فمثلًا في متجر إلكتروني قد نحدد:
Customer — العميل
Product — المنتج
Order — الطلب
Payment — الدفع
Category — التصنيف
Address — العنوان
ثم نحول كل مفهوم مهم إلى Entity، وبعدها نحدد خصائصه.
مثلًا:
Customer
id
name
email
phone
وهنا تأتي المفاتيح:
Primary Key — PK
يميز كل Record بشكل فريد.
Foreign Key — FK
يربط البيانات بين الجداول.
وباختصار:
PK identifies. FK connects.
لكن البيانات لا تعيش منفصلة، لذلك نحتاج إلى فهم Relationships:
1:1 — One-to-One
مستخدم واحد ملف شخصي واحد.
1:N — One-to-Many
عميل واحد → عدة طلبات.
M:N — Many-to-Many
الطلب يحتوي عدة منتجات، والمنتج قد يظهر في عدة طلبات.
وفي حالة M:N نستخدم غالبًا جدولًا وسيطًا مثل:
OrderItems
حتى نحافظ على تصميم منطقي ومنظم.
ثم يأتي دور:
ERD — Entity Relationship Diagram
وهو الخريطة التي توضح:
Entities
Attributes
Primary Keys
Foreign Keys
Relationships
Cardinality
قبل أن تبدأ كتابة SQL.
لكن التصميم لا يتوقف هنا.
نحتاج أيضًا إلى Normalization — التطبيع لتقليل التكرار ووضع كل معلومة في المكان الصحيح.
والقاعدة الجميلة هنا:
Store each fact in the right place.
ثم نضيف عناصر تجعل قاعدة البيانات أكثر موثوقية:
Constraints
مثل NOT NULL وUNIQUE وCHECK وFOREIGN KEY.
Data Types
اختيار النوع المناسب لكل قيمة.
Indexes
لتسريع البحث والاستعلامات عند استخدامها بشكل صحيح.
Naming
أسماء واضحة ومتناسقة.
Integrity
الحفاظ على صحة وترابط البيانات.
Performance
تصميم يناسب طريقة استخدام النظام فعلًا.
ويمكن تلخيص الرحلة كاملة هكذا:
Understand Data
↓
Identify Entities
↓
Define Attributes
↓
Choose Primary Keys
↓
Define Relationships
↓
Draw ERD
↓
Normalize
↓
Add Constraints & Indexes
↓
Validate with Real Scenarios
ثم المعادلة:
Good Data Model → Reliable Database → Better System
وأهم نصيحة:
لا تصمم قاعدة البيانات لتناسب الشاشة الحالية فقط.
صمّمها لتمثل البيانات الحقيقية والعلاقات الحقيقية داخل النظام.
Understand → Model → Relate → Normalize → Implement
سؤال للنقاش:
في متجر إلكتروني، لماذا لا نضع المنتجات مباشرة داخل جدول Orders؟
ولماذا نحتاج جدولًا مثل OrderItems؟
م. طارق العمري
Software Engineer | Backend Developer
#DatabaseDesign #Database #DataModeling #ERD #SQL #Normalization #PrimaryKey #ForeignKey #DatabaseRelationships #BackendDevelopment #SoftwareEngineering #SystemDesign #SoftwareDeveloper #SoftwareEngineer #تصميم_قواعد_البيانات #قواعد_البيانات #هندسة_البرمجيات #تطوير_البرمجيات
أي نظام ناجح لا يعتمد فقط على كود جيد، بل يحتاج إلى بيانات منظمة ومصممة بشكل صحيح من البداية.
وهنا يأتي دور:
Database Design — تصميم قواعد البيانات
الفكرة ليست أن تنشئ Tables كثيرة، بل أن تسأل أولًا:
ما البيانات التي أحتاجها فعلًا؟ وكيف ترتبط ببعضها؟
لأن التصميم السيئ قد يؤدي إلى:
تكرار البيانات، صعوبة التعديل، أخطاء في العلاقات، بطء الاستعلامات، ومشاكل تظهر كلما كبر النظام.
لذلك نبدأ عادةً بـ:
Requirements → Entities → Attributes → Keys → Relationships → ERD → Database
فمثلًا في متجر إلكتروني قد نحدد:
Customer — العميل
Product — المنتج
Order — الطلب
Payment — الدفع
Category — التصنيف
Address — العنوان
ثم نحول كل مفهوم مهم إلى Entity، وبعدها نحدد خصائصه.
مثلًا:
Customer
id
name
phone
وهنا تأتي المفاتيح:
Primary Key — PK
يميز كل Record بشكل فريد.
Foreign Key — FK
يربط البيانات بين الجداول.
وباختصار:
PK identifies. FK connects.
لكن البيانات لا تعيش منفصلة، لذلك نحتاج إلى فهم Relationships:
1:1 — One-to-One
مستخدم واحد ملف شخصي واحد.
1:N — One-to-Many
عميل واحد → عدة طلبات.
M:N — Many-to-Many
الطلب يحتوي عدة منتجات، والمنتج قد يظهر في عدة طلبات.
وفي حالة M:N نستخدم غالبًا جدولًا وسيطًا مثل:
OrderItems
حتى نحافظ على تصميم منطقي ومنظم.
ثم يأتي دور:
ERD — Entity Relationship Diagram
وهو الخريطة التي توضح:
Entities
Attributes
Primary Keys
Foreign Keys
Relationships
Cardinality
قبل أن تبدأ كتابة SQL.
لكن التصميم لا يتوقف هنا.
نحتاج أيضًا إلى Normalization — التطبيع لتقليل التكرار ووضع كل معلومة في المكان الصحيح.
والقاعدة الجميلة هنا:
Store each fact in the right place.
ثم نضيف عناصر تجعل قاعدة البيانات أكثر موثوقية:
Constraints
مثل NOT NULL وUNIQUE وCHECK وFOREIGN KEY.
Data Types
اختيار النوع المناسب لكل قيمة.
Indexes
لتسريع البحث والاستعلامات عند استخدامها بشكل صحيح.
Naming
أسماء واضحة ومتناسقة.
Integrity
الحفاظ على صحة وترابط البيانات.
Performance
تصميم يناسب طريقة استخدام النظام فعلًا.
ويمكن تلخيص الرحلة كاملة هكذا:
Understand Data
↓
Identify Entities
↓
Define Attributes
↓
Choose Primary Keys
↓
Define Relationships
↓
Draw ERD
↓
Normalize
↓
Add Constraints & Indexes
↓
Validate with Real Scenarios
ثم المعادلة:
Good Data Model → Reliable Database → Better System
وأهم نصيحة:
لا تصمم قاعدة البيانات لتناسب الشاشة الحالية فقط.
صمّمها لتمثل البيانات الحقيقية والعلاقات الحقيقية داخل النظام.
Understand → Model → Relate → Normalize → Implement
سؤال للنقاش:
في متجر إلكتروني، لماذا لا نضع المنتجات مباشرة داخل جدول Orders؟
ولماذا نحتاج جدولًا مثل OrderItems؟
م. طارق العمري
Software Engineer | Backend Developer
#DatabaseDesign #Database #DataModeling #ERD #SQL #Normalization #PrimaryKey #ForeignKey #DatabaseRelationships #BackendDevelopment #SoftwareEngineering #SystemDesign #SoftwareDeveloper #SoftwareEngineer #تصميم_قواعد_البيانات #قواعد_البيانات #هندسة_البرمجيات #تطوير_البرمجيات
❤1
#019 — UI/UX Design | تصميم واجهة وتجربة المستخدم
قد يكون النظام قويًا من ناحية البرمجة، سريعًا، وآمنًا…
لكن إذا لم يعرف المستخدم أين يضغط؟ ماذا يفعل؟ وما الخطوة التالية؟ فالتجربة ما زالت سيئة.
وهنا يأتي دور:
UI/UX Design — تصميم واجهة وتجربة المستخدم
الفرق بينهما بسيط:
UX — User Experience
يركز على كيف تعمل التجربة.
هل الخطوات منطقية؟
هل يصل المستخدم إلى هدفه بسهولة؟
هل توجد خطوات زائدة؟
هل رسائل الخطأ واضحة؟
هل يعرف ماذا يفعل بعد ذلك؟
أما:
UI — User Interface
فيركز على كيف تبدو الواجهة.
الألوان، الخطوط، الأزرار، الأيقونات، المسافات، ترتيب العناصر، والحالات البصرية.
بمعنى مختصر:
UX = How it works
UI = How it looks
لكن التصميم الجيد لا يبدأ بالألوان.
يبدأ بسؤال:
من هو المستخدم؟ وماذا يريد أن ينجز؟
فالمستخدم الذي يدخل تطبيقًا لحجز رحلة لا يريد مشاهدة أجمل Animation…
هدفه غالبًا:
Search → Choose → Book → Pay → Confirm
ولهذا نرسم أولًا:
User Flow
أي المسار الذي سيمر به المستخدم للوصول إلى هدفه.
وكل خطوة إضافية يجب أن نسأل عنها:
هل هي ضرورية فعلًا؟
بعد فهم الرحلة ننتقل إلى:
Sketch → Wireframe → Prototype → Visual UI → Development
وهنا قاعدة مهمة جدًا:
Structure First → Style Later
لأن Wireframe سيئًا بألوان جميلة…
يبقى تجربة سيئة.
ثم يأتي دور Visual Hierarchy.
فنستخدم:
Size للحجم.
Contrast للتباين.
Spacing للمسافات.
Alignment للمحاذاة.
Typography للخطوط.
Color لتوجيه الانتباه.
الهدف ليس أن نجعل كل عنصر بارزًا.
بل أن نجعل المستخدم يعرف:
ما المهم الآن؟ وما الذي يجب أن أفعله بعده؟
ثم نحتاج إلى Design System حتى لا تصبح كل شاشة عالمًا مختلفًا.
نحدد نظامًا موحدًا لـ:
Colors — Typography — Buttons — Inputs — Cards — Icons — Spacing — States
لأن:
Consistency reduces confusion.
لكن هناك نقطة غالبًا ما تُنسى:
لا تصمم Happy Path فقط.
صمّم أيضًا للحالات الإستثنائية:
Loading
Empty State
Validation
Error
Success
Disabled
فالمستخدم لا يحكم على النظام فقط عندما يعمل كل شيء بشكل مثالي…
بل أيضًا عندما تحدث مشكلة.
بدل:
Error 504
الأفضل أن تقول للمستخدم:
تعذر إتمام العملية حاليًا.
لم يتم خصم المبلغ. حاول مرة أخرى.
لأن:
A good UX explains what happened and what to do next.
ويمكن تلخيص رحلة UI/UX هكذا:
Understand Users
↓
Define Goals
↓
Map User Flow
↓
Create Wireframes
↓
Build Prototype
↓
Design Visual UI
↓
Handle All States
↓
Test with Users
↓
Improve
والمعادلة الأهم:
User Needs + Clear Flow + Consistent UI = Better Experience
وفي النهاية، المستخدم لا يهتم بعدد الساعات التي قضيتها في التصميم…
هو يهتم بسؤال واحد:
هل استطعت إنجاز ما أريد بسهولة؟
سؤال للنقاش:
لو كان لديك تطبيق حجز يحتاج 9 خطوات لإتمام الحجز، هل تبدأ أولًا بتغيير الألوان؟
أم تبدأ بتحليل الخطوات نفسها وتقليلها؟
سؤال للبحث (:
(Wireframes & Prototypes)
ما الفرق بين Sketch وWireframe وMockup وPrototype؟ ومتى نستخدم كل واحد؟
م. طارق العمري
Software Engineer | Backend Developer
#UIUX #UIDesign #UXDesign #UserExperience #UserInterface #UserFlow #Wireframe #Prototype #DesignSystem #VisualHierarchy #ProductDesign #Usability #SoftwareEngineering #SoftwareDesign #FrontendDevelopment #SoftwareEngineer #هندسة_البرمجيات #تصميم_واجهات #تجربة_المستخدم #تصميم_البرمجيات
قد يكون النظام قويًا من ناحية البرمجة، سريعًا، وآمنًا…
لكن إذا لم يعرف المستخدم أين يضغط؟ ماذا يفعل؟ وما الخطوة التالية؟ فالتجربة ما زالت سيئة.
وهنا يأتي دور:
UI/UX Design — تصميم واجهة وتجربة المستخدم
الفرق بينهما بسيط:
UX — User Experience
يركز على كيف تعمل التجربة.
هل الخطوات منطقية؟
هل يصل المستخدم إلى هدفه بسهولة؟
هل توجد خطوات زائدة؟
هل رسائل الخطأ واضحة؟
هل يعرف ماذا يفعل بعد ذلك؟
أما:
UI — User Interface
فيركز على كيف تبدو الواجهة.
الألوان، الخطوط، الأزرار، الأيقونات، المسافات، ترتيب العناصر، والحالات البصرية.
بمعنى مختصر:
UX = How it works
UI = How it looks
لكن التصميم الجيد لا يبدأ بالألوان.
يبدأ بسؤال:
من هو المستخدم؟ وماذا يريد أن ينجز؟
فالمستخدم الذي يدخل تطبيقًا لحجز رحلة لا يريد مشاهدة أجمل Animation…
هدفه غالبًا:
Search → Choose → Book → Pay → Confirm
ولهذا نرسم أولًا:
User Flow
أي المسار الذي سيمر به المستخدم للوصول إلى هدفه.
وكل خطوة إضافية يجب أن نسأل عنها:
هل هي ضرورية فعلًا؟
بعد فهم الرحلة ننتقل إلى:
Sketch → Wireframe → Prototype → Visual UI → Development
وهنا قاعدة مهمة جدًا:
Structure First → Style Later
لأن Wireframe سيئًا بألوان جميلة…
يبقى تجربة سيئة.
ثم يأتي دور Visual Hierarchy.
فنستخدم:
Size للحجم.
Contrast للتباين.
Spacing للمسافات.
Alignment للمحاذاة.
Typography للخطوط.
Color لتوجيه الانتباه.
الهدف ليس أن نجعل كل عنصر بارزًا.
بل أن نجعل المستخدم يعرف:
ما المهم الآن؟ وما الذي يجب أن أفعله بعده؟
ثم نحتاج إلى Design System حتى لا تصبح كل شاشة عالمًا مختلفًا.
نحدد نظامًا موحدًا لـ:
Colors — Typography — Buttons — Inputs — Cards — Icons — Spacing — States
لأن:
Consistency reduces confusion.
لكن هناك نقطة غالبًا ما تُنسى:
لا تصمم Happy Path فقط.
صمّم أيضًا للحالات الإستثنائية:
Loading
Empty State
Validation
Error
Success
Disabled
فالمستخدم لا يحكم على النظام فقط عندما يعمل كل شيء بشكل مثالي…
بل أيضًا عندما تحدث مشكلة.
بدل:
Error 504
الأفضل أن تقول للمستخدم:
تعذر إتمام العملية حاليًا.
لم يتم خصم المبلغ. حاول مرة أخرى.
لأن:
A good UX explains what happened and what to do next.
ويمكن تلخيص رحلة UI/UX هكذا:
Understand Users
↓
Define Goals
↓
Map User Flow
↓
Create Wireframes
↓
Build Prototype
↓
Design Visual UI
↓
Handle All States
↓
Test with Users
↓
Improve
والمعادلة الأهم:
User Needs + Clear Flow + Consistent UI = Better Experience
وفي النهاية، المستخدم لا يهتم بعدد الساعات التي قضيتها في التصميم…
هو يهتم بسؤال واحد:
هل استطعت إنجاز ما أريد بسهولة؟
سؤال للنقاش:
لو كان لديك تطبيق حجز يحتاج 9 خطوات لإتمام الحجز، هل تبدأ أولًا بتغيير الألوان؟
أم تبدأ بتحليل الخطوات نفسها وتقليلها؟
سؤال للبحث (:
(Wireframes & Prototypes)
ما الفرق بين Sketch وWireframe وMockup وPrototype؟ ومتى نستخدم كل واحد؟
م. طارق العمري
Software Engineer | Backend Developer
#UIUX #UIDesign #UXDesign #UserExperience #UserInterface #UserFlow #Wireframe #Prototype #DesignSystem #VisualHierarchy #ProductDesign #Usability #SoftwareEngineering #SoftwareDesign #FrontendDevelopment #SoftwareEngineer #هندسة_البرمجيات #تصميم_واجهات #تجربة_المستخدم #تصميم_البرمجيات