بسم الله الرحمن الرحيم اليوم بكمل موضوع ال
normalization اتكلمنا المرة الماضية عن موضوع ال
functional dependency شرحنا ايش عن ال functional
dependency أنه يكون عندي column بس تنتج قيمته من
columns ثانية وحكينا أبسط علاقة في ال functional
dependency اللي احنا دائماً بدنا إياها ومحتاجينها
في ال database اللي ال primary key منه بعرف بقيت
مكونات ال role columns الثانية اللي في نفس ال role
عملية ال normalization بتتم في مرحلة الرابع من ال
design هي ال schema refinement نستخدم عملية نسميها
decomposition تقسيم ال relations ناخذ ال relation
اللي مش معمول لها normalization و نقسمها ل relations
أسهل هذا الكلام بيخلصني من ال redundancy و المشاكل
المتعلقة بال redundancy لكن بدي أراعي أنه يبقى ال
functional dependencies سليمة لما بقسم ما بدي أكسر
ال functional dependencies يعني زي ما شوفته في
المثال كنا ناخد ال functional dependencies زي ما
هي و نعملها table جديد redundant يمين مشاكلها
بالإضافة أنها تعملي redundant storage يعني storage
زيادة تعملي مشاكل في insert و في delete و في ال
update نسميها insert و update و delete anomalies
شذوذ مشاكل رح ناخذ أمثلة عليها و نشوف ايش المشاكل
ممكن تعملها فاحكي أنا بدي أضبط ال functional
dependencies عشان أظل عندي integrity لل
constraints مينفعش أجيب functional dependency و
أكسرها من النص و احكي بأن أنا بدي أقسم ال relation
لا بدي أقسم ال relation و احافظ على ال functional
dependencies تكون في ال relations لحالها مع بعض ال
decomposition فكرة أن أنا ببدأ ب relation فيها
مثلاً أربع columns بطلع two relations لكن ال
relations دول اثنين لابد أن يكون في columns مكررة
عشان تعملي العلاقة ال foreign key مع ال primary
key ليه referential integrity constraint كلام
هذا نفسه أهم نقطة احنا بنركز عليها لما بنبدأ في
tables فيها مشكلة ال atomic elements atomic
elements عكس كلمة multivalue attribute multivalue
attribute يعني أنه يكون عندي أكثر من value في نفسه
تقاطع الكلّهم مع الروح عكسها الشيء اللي أنا بدّي
أنه يكون عندي atomic elements ما فيها القيمة
واحدة ال phone number رقم واحد الاسم رقم واحد
العلامة رقم واحد ما يكونوش رقم فاصلة رقم فاصلة رقم
ال طرق
اللي بنعمل فيها ال normalization في طريقتين عمليات
باعتمدوا على مبدأ رياضي اللي هم ال synthesis و ال
decomposition احنا بنستخدم طريقة مين نتعلمها ال
decomposition فقط شرحنا كله هيكون ال decomposition
ما بناخدش الطريقة الثانية ال synthesis ايش
أهداف ال normalization أنه يكون عند ال insert و ال
update و ال delete ما فيش فيهم dependencies و ما فيش
فيهم anomalies free من المشاكل هذه الهدف التالي أن
أعمل reducing لل reconstruction اللي بيلزمني لل
database بعد فترة بعد سنوات لما اجي اعمل
maintenance أنا لما باجي بعمل database لوزارة أو
لمؤسسة أو لشركة بعمل ال database أو البرنامج اللي
يلعب باحتياجاتهم الحالية لأربع خمس سنين ست سنين
المؤسسات بطبيعتها بتتغير، بيصير تغييرات في القوانين
فيها، في ال rules، في طبيعة الأقسام، بتيجي أقسام
جديدة، بتروح أقسام قديمة، بيخترعوا طرق شغل جديدة،
فبتطلب أنه بعد فترة، بعد سنوات، مش بعد يوم ولا بعد
شهر، بعد سنوات، أنه نيجي نظبط البرنامج القديم،
نعمل عليه تطوير أحد أهداف ال normalization أنه
التطوير هذا يكون عبارة عن شكل إضافة على البرنامج
مش أني أضطر أمسك ال tables نفسي و أكسرها و أغيرها
و أدخل columns من table على table و نسير نعمله يعني
مكرونة لا يكون التصميم جاي بطريقة أو بأسلوب أن
أنا بدي أضيف إضافة أشبهكم إياه في اللي بيبني بيت
يعني لو واحد بيبني بيت و حاطط في باله هدف إنه أنا
في المستقبل بدي أتوسع ممكن هو يصمم البيت المهندس
يصمم البيت بحيث إنه قابل إنه يضيف جنبه كمان غرفة
أو غرفتين أو كمان منافع زيادة أو كده بس لو هو في
الأصل مش حاطط في باله الكلام هذا وأجل يظبط البيت
هيلاقي حاله مضطر يكسر كل الغرف و كل المطبخ و كل
الحمام و البلاط و يخلّع كله من أول وجديد و يشتغل
شغل جديد عشان يوسع البيت مش هيك اللي بيصير احنا
اللي بدنا إياه أن احنا نعمل database بحيث أن في
المستقبل يكون فيه سهولة في عملية ال restructuring
ال redesign بعد فترة من الزمن الكلام هذا ما يتحققش
إلا إذا كانت ال database normalized الهدف الأخير
لما بيجي مبرمج غيري، غير اللي برمج البرنامج، بده
يعمل عليه صيانة أو تطوير و بيكون ال database معملها
normalization بيقدر يفهم ال database بكل صورة مجرد
ما يشوف ال tables و ال columns بدون ما حد يشرح له
لحاله بيفهم ايش بتشتغل و ايش بتعمل لأنها بتكون
more informative لل user أما لو كانت كلّه داخل في
كلّه فيه dependencies كتير في ال database ممكن حتى
لو أجه مبرمج بعدي و شاطر و بفهم في ال database
ما يفهمش أو ما يعرفش ايش المطلوب أو يشتغل على أساس فهم
معين هو فاهمه و بعدين يكون فيه مشاكل في ال update
و في ال delete بدي
أتكلم عن ال crude anomalous ال crude اللي يختصر ال
creation يعني ال insertion ال R لل retrieval ال
select ال update و ال delete المشاكل اللي ناتجة عن
ال un-normalized database في الحالات هذه مش أنا
صار لي ساعة بحكي بتعملي مشاكل في ال delete و في ال
update لنشوف أمثلة هي أول مثال بتتكلم عن update
anomaly مشروع بالتفصيل رغم أني شرحته للمحاضرة اللي
فاتت لكن هي مثال مع التفصيل طبعاً طلعوا على ال
table هذا ال table هذا فيه اندي employees skills
أنا اعمل table بسجل فيه الموظفين و ايش عندهم مهارات
حضر قانون الموظف وعنوانه ايش عنده مهارة؟ عنده
مهارة في ال typing، في الطباع، عنده مهارة في ال
short handing، عنده مهارة في ال public speaking،
في الخطابة، عنده مهارة في النجارة carpentry؟ لاحظوا
ما فيه ايدي موظف عنده مهارتين، فايش هي؟ حطيت رقم
مهارتين، 519، و ال address مرة هو عنده مهارة في ال
public speaking، في الخطابة و لبق في التحدث و عنده
مهارة في النجارة، في ال carpentry لما جينا نعمل
update على address تبعه و عملنا update في مكان
و نسينا المكان الثاني لما بيجي واحد بعدنا الآن يعمل
query يعرف ال address عنوان الموظف الرقم 15519 أنّه
address فيهم الأول ولا الثاني الصح مش عارفين ليش
لأن احنا فعلياً عشان أحدث ال address تبعه لازم أحدث
ال address تبعه في كل مكان هو فيه Skill يعني لو
عنده خمسة skills بدي أروح أحدث ال address سبعة و
كم مرة خمس مرات الصح لو ال data معمول لها ال
normalization مظبوط أحدث في مكان واحد و وين ما
يعمل ال queries تكون النتيجة واحدة الحل أن هذه
بتاعة normalization ال insertion anomaly لو أنا
عندي table لل instructors اللي في الجامعة
تاريخ تعيينه و ال code تبع ال course اللي هو بيدرسه
لو عندي مدرس مثلاً زي الدكتور علي بدرس مدتين هحط
رقمه مرتين و اسمه مرتين و تاريخ تعيينه مرتين و هحط
له مدرس كمبيوتر 101 و كمبيوتر 102 بينما مدرس مثلاً
الدكتور محمد بدرس مدة واحدة مثلاً English 206 لحد
الآن فاش مشاكل طب لو عينّا دكتورة جديدة الدكتورة
أملوا لسه معايا أنا جديد و ما بدرسش ولا مسافر، كيف
بيعملها insertion؟ على الجدول هذا؟ ما فيش حل غير
أني أحاول أضحك على ال table و أني أحط الهابط و
أقولها اسم و تاريخ تعيين و أحط محل لكورسات نابس هي
الحل الوحيد و هذا insertion anomaly مشكلة في ال
insertion الأصل أن أكون عندي قدرة أني أسجل
معلومات الموظف و أسجل معلومات ايش الكورسات اللي
بيدرسها بمعنى أن أنا فعلياً بدي two tables فهد أفصل
بدي two tables فهذا اسمه insertion anomaly نفس ال
table هذا بيعمل ليه deletion anomaly لو الدكتور
محمد هذا الفصل هذا طالع في مؤتمر مسافر على ألمانيا
على أمريكا مش هيدرس ولا course فهنيجي على الكورسات
اللي هو بيدرسهم نعملهم delete delete delete لما
نحذف كل الكورسات اللي هو بيدرسهم بيظل له record في
ال database لا إذا ابطن عندي لا رقمه ولا اسمه ولا
تلقتي عينّة إيش الحل؟ الحل لو كان بيدرس خمس كورسات
إن أنا أتحاول على الـ database أروح أحذف أربعة منهم
والأخير آجي أعمل .. مش أعمله delete أعمل update
فالـ course code يصير null يعني فعلياً عملية الـ
delete بدل ما كانت delete لحالها صار بدي delete مع
update وبده يعد كمان لازم أعد إن هو عنده خمس
records عنده ستة لأ معناه أنت بده تحذف أقل من واحد
وإذا رحت ما حذفتش ولا واحد فيهم من الخمسة ورحت
عليهم كلهم وعملتهم null ما حذفتش الخمسة أصلاً الـ
database مش هترضى لإنه هيصير كل الـ record
duplicate كل الـ record هيصير duplicate مش هترضى
فيه الـ database فهذا بيعمل إيش اسمه deletion
anomaly مشكلة في الـ deletion ليش؟ لإن الـ table أصلاً
مش normalized عشان هيك لازم أنا أشتغل normalization
إذا احنا اشتغلنا في step رقم 2 لما عملنا system
required analysis في step 1 وجينا على step 2 لما
عملنا الـ ER model conceptual design إذا احنا
اشتغلنا صح إن كل object في الـ real world عملنا
entity لحال وقسمنا الـ entity الصح هتطلع معنا الـ
database almost almost يعني normalized يعني هيكون
ضايل علينا بس إيش؟ يمكن تابل يمين تابل شمال هيك فالت
منها بيكون بده normalization لكن إذا من أصل
اشتغلنا شغل غلط هلاقي أن معظم الـ tables أصلاً بدها
يعازف normalization من أول وندين الموضوع
الـ minimizing للـ redesign اتكلمت أنا عنه إنه احنا
لو كانت أصلاً normalized الـ database فإن احنا نضيف
الـ new types أو الـ new relations على الـ database
هتكون عملية سهلة وفهم الـ database بتكون سهل
للمبرمجين أو الناس اللي بتشتغل معنا وممكن الـ
applications بتاعتنا تكون
يعني بتتأثر تأثير بالحد الأدنى minimal affected في
حالة لما أنا بعمل reconstruction الـ database بعد
عدة سنوات حكينا إن هو هي الخطوة يفترض أنّهـ الخطوة
الرابعة في الـ design صح؟ مش هيك أخدنا؟ وحكينا إن
عملت الـ normalization الهدف منها أن أعمل
simplification للـ database أبسطها وأتخلص من بعض
المشاكل اللي بتكون في الـ un-normalized database زي
إيش المشاكل اللي ممكن تواجهني لو كانت الـ database
مش normalized الـ redundancy الـ insertion والـ
delete والـ update anomalies تمام زائد مشاكل في الـ
redesign في المستقبل تصبح الـ redesign مش minimal
تصبح أصعب في المستقبل كلمنا عن الكلام هذا، كلمنا إن
احنا في طرق لعملية الـ normalization أهم طريقة اللي
احنا بناخدها اللي هي طريقة إيه؟ decomposition
فكرتها إن أنا أخد relation وإيش أعمل فيها؟ أقسمها
لـ relations أصغر، أقسمها لـ relations أصغر لكن بدي
أراعي أثناء التقسيم إن أحافظ أول إشي على
functional dependencies functional dependencies
أخذهم مع بعض في الـ relations الجديدة وأربط بين الـ
relations الجداد لصغار لازم نربط بينهم من خلال الـ
primary key و foreign key يعني في عندي أعمدة لازم
تتكرر مثلًا لو أخدنا أربع columns a,b,c,d لما ده
أقسمهم مش هعملهم a,b و c,d هقسم بحيث أن يكون في
كلهم مثلًا a,b مع b,c,d ثم هاي الـ b مكرر بحيث أنه
يربط primary مع foreign
حكينا إنه عشان احنا نبدأ في الـ normalization أول
خطوة أن أتأكد أن القيم اللي عندي في الـ column تكون
atomic elements إذا صارت القيم atomic elements
بيكون احنا في الـ first normal form والكلام هذا
علمناكم إياه من بداية الـ database design في chapter 2
و3 حكينالكم إنه مابدنا الـ many to many relations
مابدنا الـ attributes يكون فيها multi value وهذا
معناه ضمنياً إن احنا في الـ first normal form
هذا كله اتكلمنا عنه وشوفنا المرة اللي فاتت أمثل على
الـ update anomalies وعلى الـ insert والـ delete
anomalies كيف إن الـ data إذا مش normalized ممكن
يصير عندي مشاكل وتكلمنا في نهاية المحاضرة الماضية
أنه إذا كانت الـ data normalized يصير فيه سهولة للـ
redesign في المستقبل بحيث أني أضيف tables أو
relations مش أني أكسر أو أخبط الـ relations اللي
موجودة من أول وبالتالي أنا بضمن إنه أي عملية تغيير
في المستقبل تكون smooth سهلة وإيش؟ والـ
applications اللي عندي تعيش أطول فترة ممكنة آخر
نقطة بتهمني في الـ normalization الـ normalization
بتخلي الـ database design اللي عندي more
informative لـ الـ users التانين أو لـ designers أو لـ
programmers التانين بيقدروا يفهموا الـ database
بمجرد أنهم يطلعوا على الـ tables والـ relations والـ
columns اللي عندي إذا كان معمولها الـ
normalization بشكل صحيح بيفهموا الـ database كيف
تشتغل بدون أي تعقيدات لأن إذا في anomalies معناته
عملية الـ insert والـ delete والـ update بدها إيش؟
بدها يعني tricks زي ما شوفنا في مثال تبع الـ
deletion أني هأعمل delete وأخلي آخر سطر وأحط فيه
null الكلام هذا ما ببينش لـ programmer جاي على
database موجودة من أول فيها tables كتيرة مش هيبين
معاه مباشرة التالي الـ normalization بسهل على الـ
designers التانية حكينا إن الـ Unnormalized Form من
الـ database ما بنفعش نستخدمها في الـ relational
database model حكينا إن الـ relational database
model أهم شيء بالنسبة إليها على الأقل لازم الـ
normalization يكون في أي درجة
الدرجة الأولى أساسية حكينا الـ first normalization
أساسي للـ relational database model الـ unnormalized
form الـ UNF مش ممكن نهائياً تكون موجودة عندي في الـ
relational database ما بتشتغلش الـ database عشان هيك
أيام ما أخدنا الـ design قبل ما ناخد الـ
normalization حذرناكم إنه ممنوع الـ multivalue وممنوع
ممنوع الـ many to many relations عشان نضمن من دون
ما نحكيلكم إنه نضمن إن احنا نكون وين؟ دائماً في الـ
first normal form ما نكونش في unnormalized إذا كانت
unnormalized معناته في عندي data redundancy بشكل
كبير وهتسبب لي مشاكل في الـ delete وفي الـ insert وفي
هذا الكلام كيف بنعرفه؟ مجرد ما نطلع على الـ table
إذا كان الـ table في multi value في نفس الـ column
أو في نفس الـ attribute أو complex data structures
في نفس الـ field معناته احنا إيش؟ un-normalized أو
إذا احنا ضحكنا على حالنا وروحنا عاملين اللي هو
نظام telephone one telephone two telephone three
تسجيل الطلاب للكورسات course one course two course
three لو الطالب بده يسجل course أربعة إيش بنعمل؟
بنعدل الـ table فبرضه إذا احنا كانت الـ field
replicated مكررة بينما هي فعلياً بتعكس نفس
المعلومة هي كلها courses أو كلها تليفونات أو كلها
addresses أمثلة لو كان عندي tables بالشكل هذا هدول
الـ two tables لنفس المعلومات un-normalized ما فيش
فيهم أي نوع من الـ normalization ليش؟ في عندي هاي
رقم للطالب فيه اسم والكورسات اللي مسجلهم هالعظم
الطالب هذا مسجل كورسين صار عندي كام value؟ two
values ومسجل mathematics رياضيات و chemistry
كيمياء الطالب الثاني تم سجل مادة واحدة الثالث تم سجل
مادتين ففي عندي multivalue هذا normalize الـ table
هذا مباشرة لو أجى في الامتحان إيش بنحكي عنه؟
unnormalized form لو اجى واحد ثاني حكاية بسيطة
احنا بنخليها one value ورا عملي زي هيك course one
و course two هيصارت single value هل هذه normalized
برضه مش normalized هذه برضه un-normalized form لإن
احنا ضحكنا على حالنا بس كررنا نفس الـ column هو نفس
الـ column بس اشترينا نسمي course one course two طب
هذا إيش مشكلته؟ لو أربع مشاكل أو ثلاث مشاكل أول شيء
اللي ما عنده two courses هنخزن له نار يعني هياخد
مساحة على الفاضي لو اجانا المشكلة ثانية لو اجانا
واحد يسجل ثلاث كورسات أو أربعة مش هنقدر نعمله شيء
لازم نغير في الـ database نفسها تغيير جذري في الـ
design أن أضيف columns جديدة هذا الأمر بتطلب الـ
programmers يعني مش الـ user اللي بيشتغل على الـ
database مش الموظف تبع القبول والتسجيل أو رئيس
القسم اللي بيسجل المواد بيغير على الـ table لازم
نجيب الـ programmer اللي عمل الـ database يجيب وي
يغير على الـ table المشكلة الثالثة اللي بيعمل إياها
أنه عمل الترتيب ما لهوش معنى طب ليش ال
mathematics؟ في واحد مش في اتنين إيش المعنى؟ إيش
المغزى؟ ليش الترتيب هذا هيك صار؟ ليش في address
واحد و address اتنين؟ أو address تلاتة ليش هدف
الأول و هدف الثاني؟ طب مش ممكن طالب ثاني غيره برضه
مسجل رياضيات و chemistry أجي أحطله ال chemistry في
الأول و الرياضيات بعدين طب ليش هدف هدف .. في ال
column الأول و هدف ال column الثاني؟ المشكلة
الرابعة اللي بيعمليها لما أجي أعمل query عشان أشوف
الـ .. إذا الطالب مثلًا بدأ أشوف الطلاب المسجلين
في مادة الكيميا بدل ما أشوف أن ال course بيساوي
chemistry حضر أشوف أن ال course one يساوي
chemistry or course اتنين بيساوي chemistry or ال
course تلاتة بيساوي chemistry وإذا في عندي ست
كورسات ستة كلهم زي هيك or or فهتصير ال where
statement بتاعتي كبيرة وطويلة بدون أي معنى هذه كلها
من مشاكل unnormalized form طيب قبل ما أنتقل على ال
slide الثاني لو عندي table بهذا الشكل كيف ممكن
أن أحوله ل normalized form قبل
ما أفصل أي جدول الحل أول حل سريع عشان أصبِح في ال
first normal form أن أكرر ال rows ال mathematics و
ال chemistry هدول يتكرروا يعني أصبِح أكتب زي هيك
one jack اسمه mathematics one jack chemistry تمام
two tim اسمه chemistry ال three ايش اسمها أنا
physics
ال three أنا ايش عندها chemistry لكن ايش المشكلة
اللي صارت عندي وين كان ال primary key كان يفترض ..
يفترض أن يكون ال ID صح؟ لأن هل بنفع يكون ال ID هو
ال primary key؟ لأن هذه صارت first normal form
ما عندي أعمدة مكررة بنفس الاسم بتخدم نفس الهدف
وما عندي multi value attributes هذه first normal
form لكن المشكلة أن ال primary key تبعها كبير كثير
إيش ال primary key؟ ال primary key عندي صارت تلاتة
كلهم مع بعض رقم الطالب مع المادة أو رقم الطالب مع
الاسم مع المادة يمكن أبسط براي ماريكي اللي هو رقم
الطالب مع المساق يعني two fields combined
disadvantages لل unnormalized أول شيء absence of
relations ما فيش relations حقيقية لما نكون
unnormalized احنا حكينا ال relational database
model أقل شيء لازم يكون في ال first normal
unnormalized معناته ما فيش relations صحيحة إذا أول
شيء غياب ال relations الحقيقية absence of
relations المشكلة الثانية اللي هي ال crude
operations anomalies مشاكل ايش ال crude حكيناه
اللي هي ال insert و ال delete و ال update و ال
select مشاكل ال creation retrieval update and
delete crude operations anomalies شرحناهم فهدول
كلهم فيهم مشاكل وهي كمان مثالين على table ل
customers عندي unnormalized عندي ال customer ID ال
first name ال second name ال sure name اسم العائلة
وعندي ال telephone طلعوا في رقم فاصلة كمان رقم two
values عندي رقم وحطيتله extension وكمان رقم وأنا
رقم واحد في الجدول الثاني برضه جيت كررت نفس
العملية روحنا عملنا لـ telephone number one
telephone two وحطينا كل واحد لحالة هدول برضه
الاثنين مالهم حسب اللي اخذناه واللي تعلمناه الآن
هدول بدأ أفهم أول ما أشوفهم أعرف أنهم form un
-normalized الحل بشكل زي هيك هذا عشان أكون لسه في
ال first لسه ما أخذتش ال levels الأعلى من هنا في ال
first normal form ال first normal form أول شيء
بيميزها أنّه probability لل relational database
model يعني لازم على الأقل أي table أي relation
يكون في ال first normal form على الأقل minimum
requirement طيب كيف أعرف أن أنا في ال first normal
form أنه ما يكونش عندي multi value attribute ال
domains اللي عندي لكل attribute بس يكونوا ايش
atomic قيمة واحدة إذا كانت قيمة واحدة هذه بتكون في
ال first normal form اللي هي essential property لل
relational model وأنا أكون في relational database
خصائص ال first normal form ال criteria بتاعتها أول
شيء بدنا نعمل eliminate لل repeating groups في ال
individual tables ما يكونش فيه تكرار أرقام هاتف
تكرار addresses تكرار أرقام
تليفونات تكرار courses زي الأمثلة اللي شفناها يا
مريم create a separate table for each set of
related data باخد ال data بتاعتي بحطها كل data
مرتبطة مع بعض بحطها في table لحالها النقطة
الثانية والأولى هم أهمتين ثانية النقطة الثانية
لازم يكون في عندي primary key نعمل table ما فيش في
primary key غير مقبول عشان يكون عندي primary key
لازم يكون عندي على الأقل one ال primary key من وين
بنجيبه؟ من candidate key فلازم على الأقل عندي one
candidate key عشان يصير هو ايش ال primary key فإذا
الجدول ما فيش فيه key بدي أدور له على key زي لما
رسمنا الجدول هذا بطل ال ID بنفع primary key فروحت
أدور مباشرة وأروح أدور عشان أعرف وين ال primary
key اللي عندي إذا ما فيش مثلًا الآن زبط عندي في
الجدول هذا زبط أنه يكون ال ID مع ال course بس لو
ما فيش لازم أنا أروح أضيف كمان column أحط فيه مثلًا
أرقام أسميه order ID لو كان orders لو كان students
أسميه student ID لو كان موظفين أسميه employee ID
هذه من أين تيجي ال columns هذه أنا اللي باختلقها
أنا ال employee العادي في ال database له اسم له
رقم هوية له عنوان له راتب ماله ايش اسم employee ID
ما حدش بيجي من بيت أهله له ايش اسم employee ID هذا
ايش أنا اختلقته عشان أعمل primary key لل table تمام
فاحنا لازم يكون فينا primary key ما فيش repeating
وفي primary key إذا احنا first normal form المثال
اللي فرجيناكم إياه قبل شوي تبع ال customers بدي
أحوله لـ first normal form لما هنيجي نحوله لـ first
normal form ايش حاجة أعمل؟ نفس الفكرة اللي عملناها
قررنا الأرقام والأسماء قررنا وحطينا الأرقام صار
مثلًا اللي كان عنده رقمين صار له two rows اللي
كان له رقمين برضه نفس الشيء اللي له مثلًا رقم واحد
بيكون له entry واحدة اللي له تلت أرقام هيصير له
three rows هل في ايش في ال design هذا هل في ايش
بيمنعني أن أحط لواحد عشر أرقام تليفون بينما ال
design هذا كان بيمنع ولا لأ؟ كان بيمنع إذا
أنا هيك في ال first normal form عشان اروح لل
second و third normal form لازم أطلع على ال
functional dependencies ال first normal form بس
كنا نطلع على ال multivalue attributes الثاني والثالث
يجب أن ينظر إلى الـ functional dependencies يجب أن
أكتبهم ثم أقول إنني أريد أن أتحول إلى ثاني أو ثالث
لنرى مع بعض في هذه الطاولة أين يوجد الـ
dependencies أولًا أين ال keys دائمًا ال keys يوجد
مرتبط معهم dependencies صح؟ ليس ال keys ال super
key و ال candidate key يعطوني بقية الرؤية يعني هذه
ال dependencies يعطوني ال keys أين ال key؟ الرقم
لحاله key لحاله key الرقم لأنه مكرر طب الرقم مع
الاسم بيعطيني key؟ لأ الرقم مع التليفون إذا هي أول
شيء عندي ال ID مع التليفون بيعطوني ايش بقية ال
columns اللي هم مين ال first و ال sure name بيعطوني
ال first هيبدأ أسمع أسماء ال columns اختصارات عشان
الكل يكون مين تبين معه وهذا ال telephone وهذا
سميناه ال ID ال ID و ال first و الشور و ال
telephone ال ID و ال telephone عطوني مين ال first
و الشور و هدول عبارة عن ال primary key الاثنين مع
بعض combined primary key طب هل في dependences
ثانية؟ ال name بعتمد على الرقم أنا بعرف ال first و
ال sure name من الرقم مجرد ما تعطيني الرقم بعرف
مين هو الاسبوعي مش من رقم وبعرفه مين هو إذا أنا
عندي ال ID بتعطيني مين بتعطيني ال first و ال sure
name بتعطيني
التليفون هل معرفتي اللي ال ID بيعطيني التليفون طب
هي عندي ID أعطاني اثنين تليفون مش واحد
ما أعطانيش اياه مش functional dependent طيب
هل التليفون بيعطيني الاسم في الجدول اللي احنا
شايفينه بيعطيني الاسم في الجدول اللي هذا بيعطيني
الاسم بس أنا ده افترض انه لأ ما بيعطانيش يعني ممكن
مثلاً تليفون لسبوع مثلاً عندي اثنين أخوة زبائن و
الاثنين حطوا الاثنين حطوا تليفون للبيت فانا بدي
أشغل برضه مخي، ماشي بس بدي أطلع عدات، هذا مثال،
example، بحلل أنا واقع، في تحليل الواقع أنه لأ
ممكن اثنين يكونوا نفس رقم التليفون البيت، أنه في
البيت بيكونوا فيه عشرة، عشرين، واحد، اللي هم كلهم
نفس الـ .. اللي هم نفس التليفون الأرضي، هي غالباً
عندنا الواقع هيك عندنا، آه، كان زمان يعني الـ
average تبع العائلة الفلسطينية ستة أشخاص الزوج
والزوجة وأربعة أبناء هذا الـ average الـ average ففي
عندك ستة أشخاص اللي هم نفس رقم التليفون على الأقل
ما بنحكيش احنا عن الجوال ما بنحكي عن جوالات الـ
telephone number طب الـ ID بيعطيني الـ first والـ
sure name الـ NID جزء من الـ primary key ولا لأ
شايفين كلمة جزء هذه الـ Primary Key حكينا أن الـ
Primary Key ما فيش عليها مشكلة أو الـ Candidate Key
ما فيش عليها مشكلة Primary Key و Candidate Key
ما فيش مشاكل مشكلتي تبدأ مع الأمور الثانية اللي مش
Candidate و مش Primary Key في عندي Dependency
بتعتمد على الـ ID والـ ID أنا بعرف أن بين واضح عندي
أنها جزء من الـ Primary Key إذا صارت إيش هذه
partial functional dependency partial functional
dependency فبدأ أخلص منها إذا أخلصت منها هكون
دخلت في الـ slide اللي بعدها اللي هو أنا بتكلم عن
مين عن الـ second normal form إذا أخلصنا من الـ
partial وجينا على الـ transitive functional
dependencies وشيلناهم هذه second normal form بيصير
أنا ويّاكم في الـ third normal form طبعاً واضح من
العلاقة اللي عندي ما في عندي شيء transitive في
المثال هذا في عندي بسبس في عندي partial فأنا إذا
أخلص من الـ partial وأصلًا ما فيش عندي transitive
حسبير وين؟ حسبير في المستوى الثالث مباشرة لما هشيل
الـ partial حسبير في الـ second وأنا أصلًا ما فيش عندي
transitive حسبير في الثالث كيف العملية بتتم؟ عن
طريق الـ decomposition هنا رسمنا الـ dependences
هآخد الـ dependences اللي مش أساسية اللي ما فيش فيها
الـ candidate keys هذه بتعملها جدول لحال ولا جدول لحال
الـ ID مع الاسم هذه هي الجدول أول جدول أول relation
الـ relation الثانية هيظل فيها الـ telephone number
وبدي أربطها مع الـ relation الأولى بدي ناخد مين الـ
ID لأن هو هيكون الـ primary key هو اللي حيصير الـ
primary key فهيصير عند الـ relation الثانية فيها ID
وبيعطيني مين الـ telephone number
هذه الرسمة بتاعتها إذا
أنا كملت إذا أنا استخدمت الـ decomposition هجيب الـ
customer ID وأربطه في علاقة one to many مع أسماء
الأشخاص الـ first name والـ short name هاي الـ table
الأول اللي هو معلومات الـ customer الـ customer name
ID primary key بيعطينا اسم كل ID بيعطينا اسم ما فيش
تكرار للـ ID الـ ID هو الـ primary key في الـ relation
الأولى هي الـ primary key في الـ relation الثانية
أجى الـ primary key صار foreign key تمام حطينا
مقابلِه رقم التليفون وصارت عند الـ relation زي ما
أنا كاتب أنها صارت second و third normal form
لو بدنا نغير اسم أي زبون كم update بدنا؟ update
واحد بس باجي بغير اسم الأول أو اسم الأخير بتغير
رقمه؟ update واحد بدي أغير رقم تليفون إله التغى كم
delete بدي؟ delete واحدة هل الـ delete هاي بتطير
معلوماته كزبون؟ لأ لأن معلوماته ضايلة في جدول
الزبون ده أضيف له رقم جديد ممكن أضيف له رقم جديد في
شيء بيمنع إذا أنا أخلصت من الـ delete ومن الـ
update ومن الـ insert anomalies الـ
second normal form عشان أنا أكون فيها لازم أكون
أنا أصلًا first normal form وفي عندي كمان
requirements الـ requirement الثانية أنه يكون ما فيش
عندي إيش اللي هو الـ partial ديبندنسي إيش
يعني partial ديبندنسي تعال نشوفها بالتعريف الثاني
الـ relation في الـ second normal form إذا كانت في
الـ first normal form and no non prime attribute
إيش يعني non prime attribute يعني أي attribute مش
جزء من الـ candidate key أي attribute مش جزء من الـ
candidate key هذا المصطلح بدنا نتعرف عليه الـ prime
الـ prime columns هم أي columns جزء من الـ
candidate مش بس الـ primary أي candidate key سواء
كان الـ primary key أو الـ candidate key مش الـ
primary الـ prime attribute هو attribute أو column
جزء من candidate key الـ non prime عكسه ما يكونش جزء
من أي من أي candidate key
في الـ second normal form لازم أكون في الـ first
normal وما فيش عندي ولا non prime attribute بيعتمد
على مين على sub set على جزء من الـ candidate key
كلمة هذه sub set من الـ candidate key يعني إيش يعني
fractional dependency partial
fractional partial جزء إيه تمام partial dependency
ما بديش الـ partial dependencies هاي معنى الكلام ما
بدي أي column مش جزء من الـ candidate keys يعتمد على
جزء من الـ candidate keys لازم يعتمد على كل الـ
candidate key كامل الـ whole candidate key إذا كان
الـ candidate key column واحد يعتمد عليه إذا كانوا
two columns combined يعتمد على اثنين مع بعض مش على
واحد منهم كانوا ثلاثة يعتمد على الثلاثة مش على
اثنين أو على واحد منهم واضحة الصورة هيه هكتبها كمان
بلغة ثانية بدل ما أحكي أنه ما بيعتمدش على الـ sub
candidate كاتب أنه dependent on the whole of every
key نفس الجملة صيغتها أكثر من صياغتها الصياغات اللي
بترسخ في مخكم احفظوها بدي أنا أي column مش prime
لأن برايم يعتمد على كل الـ key الـ whole key أو أنه
ما يعتمدش على جزء من الـ key أو تحفظ أنه أنا ما بديش
اللي هو الـ partial functional dependencies هذه
مكتوبة تحت no partial functional dependencies مثال
في عندي هذا الـ table في عندي مصنع بصنع models من
أجهزة كهربائية وهي الـ full model name وهذه الـ
country بتاعة بلد المصنع country بتاعته الـ primary
key عندنا هو هذا الـ model full name هذا هو الـ
primary key بما أنه هو الـ primary key إذا مباشرة في
عندي dependency functional dependency أن هذا
يعطيني مين تلاتة هدول هاي الـ .. الـ .. الـ F الـ
function الـ full name بتعطيني الموديل والـ
manufacturer والـ C الـ C اللي هي الـ country الـ
manufacturer والموديل واحدة، اثنين، ثلاثة خلصنا
منها؟ طيب هل من المصنع ممكن أعرف البلد؟ أكيد كل
شركة إلها بلد إذا المصنع Ford إذن Italy إذا المصنع
الكبياشي هذا معناته Japan المصنع BMW معناته
Germany معروف من اسمه بينعرف طيب إذا في عندي
dependency هايها الـ manufacturer بتعطيني مين الـ
country في عندي كمان dependency طلع عندي لو أنا
عرفت الـ manufacturer والموديل ممكن أعرف الـ full
name والـ country كمان صح هاي الـ manufacturer والـ
model بيعطوني الـ full name والـ country نيجي أول
واحدة هذه عبارة عن الـ primary key مع باقي الـ
columns هاي بتعمل مشاكل هاي ما بتعملش مشاكل هاي
مش اللي بدور عليها نيجي على الثانية هل الـ
manufacturer هذا جزء من candidate key هي ..
manufacturer مع الـ model أعطوني كل باقية الـ table
يعني هذا candidate key ثاني صح؟ والـ manufacturer
جزء منه، إذا هذه partial ولا لأ؟ partial وأعطتني
الـ country والـ country هذا نُن برايم ولا برايم؟
انسوا
كل اللي حكيته، هي .. هذه الـ country الـ country هذه
prime كيف أعرف أنها prime؟ لازم تكون جزء من مين؟
من candidate key أول شيء، هذه عندي أول candidate
key اللي هو الـ full name فيه أجزاء، ما هو كلهم
واحد، ما لهوش أجزاء كلهم واحد، ما هي له أجزاء هذه الـ
candidate key الثانية الـ manufacturer مع الموديل هذا
إيه أجزاء؟ هل الـ C جزء من هدول؟ إذا هي none؟ none
prime إذا أصبحت عندي none prime هي الـ C none
Ibrahim تعتمد
على مين؟ على جزء من كيه partial functional
dependency إذا عندي مشكلة في الـ second ولا ما فيش عندي
مشكلة؟ عندي مشكلة مريم أنا مشكلة
إن الـ non-prime يكون باعتمد على الـ partial حكينا بديش
إياه عشان أسير في الـ scan ما بدي إياه عشان أسير في
السكن بدي أتخلص منه كيف نتخلص منه decomposition
هاخد هدول و بدي أعملهم هدول هيهم اللي فيهم المشكلة
هذه اللي عليها المشكلة مشان المشكلة موجودة هي الـ
partial بدي أخده أعمله جدول لحاله تعالوا نطلعوا
جدول لحاله إيش هيصير عنده المنفعة شرار و إيشو الـ
country بس بدنا نعملهم جدول لحالي الجدول التاني
إيش هيظل فيه الـ full name و مين كمان و الـ model صح
الـ model و الـ full name و بدي أربط بين الجدولين
بدي أجيب هذا الـ manufacturer أحط خلصنا
خلصنا خلصنا non-prime مربوط مع جزء من الـ key مشكلة
هروح أاخده جدول لحاله و الباقي في جدول و بدأ أربط
بينهم الـ primary key تبع الجدول الأول ده أحطه
foreign key هايهم
هذه الجدول الأول اللي جيبنا فيه الـ dependency اللي
كان فيها المشكلة اللي هو الـ manufacturer مع الـ
country حطيناهم في جدول وهذه الجدول التاني جيبنا
فيه الـ manufacturer اللي كان primary صار foreign
لأنه هي طلع بتكرر قابل للتكرار foreign مش primary
حطينا الـ model و الـ full name الـ primary تبقى حد
الجدول مين ضل؟اللي هو أصلا مش هذا كان هو أصلا الـ
primary للعلاقة القديمة ضال هو primary للجدول هذه
في الجدول الجديد إيش العلاقات اللي عندي في الجدول
الجديدة عند الجدول اللي فوق الـ manufacturer
بيعطيني الـ C و الجدول التاني فوق اللي بيعطيني الـ
model و الـ manufacturer بس مع
مين نربط مع مين مع مين هذا
في أي جدول؟ في هذا الجدول أو هذا الجدول؟ أنا صار
جدولين عشان أتبع معاك الـ manufacturer أحط الـ full
name فوق أحطها أجيب هذه الـ primary أوديها على الـ
table هذا foreign primary في هذا الجدول صحيح تمام
لأ ما نفعش ما نفعش أنا هحكيلك ليش ما نفعش طالع عندي نفسي
المصنع بيصنع كام model بيصنع اتنين فكيف ده أربط
هذا مع المصنع العكس أنا بربط المصنع مع الـ models
وصلت؟
أنا عندي شركة بتنتج تلاجات مثلاً أنواع تلاجات أربط
رقم المنتج مع الشركة مش العكس
وصلت؟ طيب هي المشكلة وين؟ لو أنا بدي أخد هذا هو
أخده على الجهة التانية هاي fort عندي إلها منتجين
أخد هذا ولا هذا أحطه جانب fort في الجدولة ده؟
ما لهاش معنى، لأ أنا باخد المنتج للـ two models
واضحة موضوع الـ second normal form بدور على الـ
partial dependences وناخدهم في جدول غاية ده فاهمة
ولا .. أكيد ولا لأ طيب الـ third normal form طيب
ماشي خليني أشرح حدي صعبة
بدي أشبه في المشروع بدي أعطي أمثلة من المشروع عشان
نعرف بعض الأمور في المشروع عندكم مثلاً مطلوب أنه في
rooms و الـ rooms هذه لها type و لها سعر صحيح؟ في
عندي room و الـ room لها type و لها price لكن
أعطيناكم معلومة أن الـ price بيحدده مين؟طيب لو أنا
كان عندي غرفة رقمها مثلاً واحد واتنين وتلاتة واربع
وواحد واتنين هدول كانوا تنتين single نفس الـ type
وكان عندي سعر هذه سعرها تكلفتها مثلاً خمسين دولار
وهي خمسين دولار مش هذا بيعمل لي update anomaly أن
ممكن واحد ييجي يعمل update أو insert بالغلط ويعمل
هذه سعرها ستين رغم أنهم نفس الـ type ما حفظنا على
الشرط اللي احنا طلبناه أن الـ type هو اللي يحدد
السعر فبينه الـ type هو اللي بيحدد السعر الـ T
بتخليني أعرف الـ price صح؟ و الـ R أنا أصلاً منها
بعرف مين الـ type و الـ price فبدي أخد هذه هذه
transitive هذه المفروض أن أشرحها في الـ third
normal form هذه transitive الـ B بتعتمد على الـ T و
الـ T مش جزء من الـ .. مش جزء من الـ key مش partial
هذه برا non prime مع non prime Transitive
فهذه بدها normalization على الـ third normal form
لازم هذا الجدول أقسمه لجدولين إيش هقسمه الـ R مع الـ
type والجدول التاني type مع الـ price بهيك بيصير
تعديل واحد بس only one update على الـ price للـ type
يعني الـ single سعره خمسين لو عدلتوا لـ 60 كل الغرف
اللي نوعهم single هيصير سعرهم 60 هاي تطبيق مباشر
على الـ third normal form إيش
كمان بتكون ملاحظات في عندكم الـ address بتكون تروح
وتعمل الـ address entity لحالها بدنا يا attribute
ليش؟ لأنه مكتوب في المثال أن الـ address بده street
وبده city و بده .. صار له structure يعني وإحنا
حكينا الـ address ما بنفع نيجي نحكي الـ hotel إله
address ونحط الـ address attribute و الـ employee
إله address و الـ customer أو الـ guest إله address،
ما نفعش أجيبهمو أحطهم كـ text كـ string يعني لأنه أنا
طالب structure مكتوب أنه بدنا الـ address يكون city
street name street number معناته الـ address نفسه
صار له attributes وهذا الكلام شرحناه في chapter 2
لما بكون الـ object إله attributes بفصله بعمله
entity لحاله فهيكون فعلاً من الـ entities address و
الـ address هذا بديهله primary key لا الـ city هي
primary key ولا الـ street name primary key ولا الـ
street number بنفع يكون primary key بدي أنا أختلق
من عندي إيش اسميه إيش address ID أو address number
وهذا الـ primary key في جدول الـ addresses بدي أودي
foreign key لمين؟ للـ hotel و للـ customer و للـ
employee قصة الصورة برضه كمان عندكم الـ room
شوي بس .. الـ room هذه نفسها كمان أنا افترضت في
المثال هذا افترضت أن الـ room number كفاية يعرف عن
الـ room بس فعلياً هو مش كفاية لأن أنا عندي أرقام
الغرف مثلاً من واحد لمية بالضبط افترض أنها من واحد
لمية أنا فعلياً ما عنديش فندق واحد أنا عندي سلسلة
فنادق chain of hotels في الفندق الأول في غرف من
واحد لمية في التاني مثلاً أصغر منهم في من واحد
لخمسين في اللي بعده أكبر منهم لاتنين في من واحد
لميتين معناته في أرقام غرف بتتكرر طب اللي سبق حجز
أهي غرفة غرفة رقم مية في الـ hotel الأول ولا في
التاني ولا في التالت معناته بالضبط أنا بدي مع الـ
.. مع الـ room ID أو الـ room number بدي كمان من الـ
hotel إيش معنى أنه أنا بدي الـ primary تبع الـ hotel
مع الـ .. مع الـ room مع بعض معناته weak entity الـ
room بتعتمد على الـ hotel زي الـ child اللي بيعتمد
على الـ parent مش كان weak الغرفة مين أبوها؟ أبوها
الـ hotel هي غرفة في الـ hotel فده weak entity بدنا
نراعيها weak entity ونشتغل على هذا الأساس طبعاً
مش الـ guest بده يعمل order بده يطلب غرف علاقة الـ
guest مع الـ hotel من خلال الـ order طيب الـ order
أخذنا مثال عن الـ order تحديدا في chapter 2 لما
عملنا الـ bookshop تتذكروا عملنا مثال على الـ
bookshop روحنا الـ order ما عملناهوش تاب الواحد أو
entity واحدة عملنا order و order details أو order
و order sheet في الـ order روحنا اختلقنا من هنا
primary key سمينا إيش الـ order ID أو الـ order
number و بده date order date تاريخ انعمل فيه الـ
order الطلبية تاريخ ما عملنا الطلبية مش تاريخ الحجز
نُشبهها بمثال لما إحنا بنروح بنحجز قاعة لفرح بنروح
بنحجز في نفس اليوم لأ في تاريخ لحظة ما بنيجي نحجز
اللي هو مسبق قبل شهر أو شهرين تمام وفي تاريخ الحجز
نفس الشيء في عندي order date وفي عندي stay date
مكتوب في المثال الـ stay date تاريخ الحجز تاريخ الـ
stay يعني المكوث في الفندق ليلة ما بدي أنام في
الفندق الـ order date لحظة ما أنا حجزته قبل أسبوع
قبل بشهر ممكن يكون بنفس اليوم ممكن ييجي واحد سائح
وييجي ع الفندق ويقول عندكم غرفة فاضية اه في غرفة
فاضية ويحجز نفس اليوم ممكن يكونوا نفس اليوم بس
بدنا نكون فاهمين أنه ممكن يكونوا مختلفين ففي عندي
في الـ order في order ID، في date، في بعد الـ date
إيش كمان، مين الزبون اللي عمل الـ order؟ بنفع اتنين
زبائن يعملوا نفس الـ order؟ لأ ففي عندي رقم مثلاً الـ
SSN تبع الزبون، تبع الـ customer رقم هوية الـ
customer و الـ date و الـ order ID الـ order هذا إله
price إله سعر أنا مش متكلم عنه تركي الكمية تفكروا
فيه يعني زبون عمل طلبية وما دفعش سعرها الزبون اللي
بيحجز 3 غرف زي اللي بيحجز غرفة زي اللي بيحجز 10 غرف
بدنا نحسب الـ price هذا كيف بدنا نحسبه مجموع الـ
price تبع الغرف اللي حجزهم مش أنا، في عندي price
لكل غرفة اللي حجز 10 غرف بحسبله price لكل غرفة
حجزها، الـ sum أخدته في ال aggregate functions
ده روح أعمل select sum لل price للغرف اللي هو
حجزهم where ال customer ID بيساوي كذا، بكتب رقمه
فهحسب ال price، فانا بدي لل order بدي price بدي رقم
ال customer بدي date بدي order ID لأن في ال order
details في ال order sheet باجي بحكي ال order ID
اللي كان ال primary key، إيش هيصير foreign key هاي
نفسه order ID وفي ال stay date لإيش لغرفة محددة
الغرفة هي كيف بحددها بال room number مع ال hotel
number room ID مع hotel ID
هيصار عندى stay date و room ID و hotel ID مع ال
order ID، ايش كمان بلزمنيش ال assistant بال guest
في ال order details بلزمنيش، ليش؟ لإن رابط هذا
الجدول مع هذا، فلما بعمل ال query بفحص الرقم هذا مع
هذا بعرف
بدي أعرف عنوان الزبون، بربط ال query الغرفة عن طريق
ال order ID، بعرف رقمه من رقمه على جدول ال
customers بطلع عنوانه بطلع اسمه، joins مش أخدنا
joins؟ أخدنا ال where بساوي كذا and كذا نعمل
joining لل tables تمام، يعطيكم العافية