03 - Database Design Conepts

لدينا أربعة موظفين مسؤولين عن أربعة دروج تحتوي على بطاقات . كل بطاقة في درج الزبائن تمثل زبون ، و كل بطاقة في درج الفواتير هي رأس فاتورة ، و كل بطاقة في درج تفاصيل الفواتير هي تفصيل واحد لفاتورة ، و كل بطاقة في درج المواد تمثل مادة.

لا يوجد حواسب . صاحب العمل حرك يده فوق درج تفاصيل الفواتير ، و سحب بطاقة بشكل عشوائي ، و سأل: "في أي محافظة بيعت هذه؟"

البطاقة لا تحوي هذه المعلومة ، المحافظة موجودة في بطاقة الزبون الذي اشترى الفاتورة . نظر الموظف المسؤول عن درج تفاصيل الفواتير في البطاقة ، فوجد أن رقم الفاتورة في البطاقة هو 159 ، فطلب من الموظف السؤول عن الفواتير أن يبحث عن الفاتورة ذات الرقم 159 . الموظف المسؤول عن الفواتير بحث في بطاقاته عن الفاتورة ذات الرقم 159 ، و أحضرها:

وجد أن رقم الزبون هو 2 ، فطلب من الموظف المسؤول عن درج الزبائن أن يبحث عن الزبون ذي الرقم 2 . الموظف المسؤول عن الزبائن بحث في بطاقاته عن الزبون ذي الرقم 2 ، و أحضره:

جواب السؤال هو "حلب" ، المادة بيعت في حلب.

الذي حصل هو التالي:

من تفصيل الفاتورة الرئيسي ، أخذنا "رقم الفاتورة" التي يتبع لها التفصيل ، 159 ، و بحثنا عن هذا الرقم في حقل "الرقم" في درج الفواتير ، عندما عثرنا على البطاقة (الفاتورة) أخذنا "رقم الزبون" المدون فيها ، 2 ، و بحثنا عن هذا الرقم في حقل "الرقم" في درج الزبائن.

من غير المقبول أن لا نجد فاورة رقمها 159 في درج الفواتير . و من غير المقبول أن نجد أكثر من فاتورة رقمها 159.

و كذلك من غير المقبول أن لا تجد زبون رقمه 2 في درج الزبائن ، و من غير المقبول أن نجد أكثر من زبون رقمه 2.

إذن ، عندما يقوم الموظف المسؤول عن درج تفاصيل الفواتير بإدراج بطاقة جديدة ، أي تفصيل جديد لفاتورة ، يجب أن يتأكد من أن رقم الفاتورة المذكور في هذه البطاقة موجود في درج الفواتير . كما أنه من غير المقبول أن يقوم بتعديل هذا الرقم دون الرجوع إلى الموظف المسؤول عن درج الفواتير.

و عندما يقوم الموظف المسؤول عن درج الفواتير بإضافة بطاقة جديدة ، أي فاتورة جديدة ، يجب أن يتأكد من أن رقم الزبون المذكور في هذه البطاقة موجود في درج الزبائن . كما أنه من غير المقبول أن يقوم بتعديل هذا الرقم دون الرجوع إلى الموظف المسؤول عن ردج الزبائن . هناك مسؤولية أخرى تقع على عاتق موظف الفواتير: إذا أراد أن يحذف فاتورة ، يجب أن ينسق مع موظف تفاصيل الفواتير ، إما أن لا يحذف الفاتورة إن كان لها تفاصيل ، و إما أن يحذف الفاتورة و تفاصيلها . كذلك الأمر إذا أراد موظف الفواتير تعديل رقم فاتورة ، يجب أن يتحقق من عدم وجود تفاصيل ، أو ينسق مع موظف تفاصيل الفواتير بأن يعدل معه تماماً.

الموظف المسؤول عن درج الزبائن عليه نفس المسؤولية الأخير . يجب أن لا يحذف بطاقة زبون قبل أن يتأكد أنه غير مستخدم بأي فاتورة في درج الفواتير ، أو يجب أن ينسق مع موظف الفواتير بأن يحذف فواتير الزبون في حال أراد حذف الزبون . و كذلك في حال أراد موظف الزبائن تعديل رقم زبون.

و كذلك الأمر لدى موظف المواد ، يجب أن ينسق مع الموظف المسؤول عن تفاصيل الفواتير في حال أراد حذف مادة أو تعديل رقمها.

لماذا كل هذه الشروط ؟

بغية تحقيق التكامل المرجعي.

02 - Database Design Concepts

لنوسع الحديث عن مثالنا السابق . شركة لديها مجموعة أسواق تجارية لبيع المواد التموينية . لديها زبائنها و مورديها . سننظر في تصميم قاعدة بيانات مناسبة.

لدينا بدايةً جدول الزبائن:

ثم هناك الفواتير . سنقوم بتصميم قاعدة بياناتها معاً . نبدأ بنموذج الفاتورة المستخدم في الشركة . هذه هي إحدى الفواتير:

لنتأمل الفاتورة قليلاً . هناك رأس لكل فاتورة ، فيه رقهما ، و تاريخها ، و زبونها . و هناك تفاصيل لها ، في كل تفصيل لدينا المادة ، و واحدتها ، و الكمية و السعر الإفرادي و الإجمالي . ثم هناك إجمالي قيمة الفاتورة . لنبدأ بوضع تصميم أولي للجدول (أو للقاعدة):

هذه هي الحقول (و البيانات) التي تعبر عن رأس الفاتورة:

كيف سنضع التفاصيل ؟ هل نضعها هكذا:

أم هكذا:

في الحالة الأولى ، من الصعب جداً استثمار البيانات . كيف سيتم احتساب النتائج في حقل الإجماليات ، و كيف سيتم إسناد الواحدة للمادة ، السعر الإفرادي ...

في الحالة الثانية ، هناك نقص في البيانات . لا بد من تعبئة قيم حقول رأس الفاتورة أمام كل تفصيل . هكذا:

لماذا ؟ لأنه لابد من أن نقول أن مادة السكر هذه ، قد بيعت في الفاتورة رقم 156 بتاريخ 06/02/2013 لحامد ، و السمنة بيعت في الفاتورة رقم 156 بتاريخ 06/02/2013 لحامد ، و الرز كذلك ... تكرار إجباري للبيانات.

فكرة تكرار البيانات ، مبدأ إعادة إدخال نفس المعلومة في نفس الجدول ، أو في أكثر من جدول ، هو أمر سيئ ، و سيئ للغاية . تكرار البيانات مدعاة للخطأ . تكرار البيانات يبطئ من عمليات الإدخال . تكرار البيانات يستهلك مساحة تخزينية غير مبررة في الأجهزة ... تكرار البيانات هو علامة وجود شيء ما في تصميم القاعدة ... قد يكون خطأً ، و قد يكون مبرراً.

فلننظر في هذا التصميم . لنصنع جدولاً أولياً نسميه "رؤوس الفواتير" مثلاً ، نضع فيه المعلومات الرئيسية في الفاتورة ، كما ذكر قبل قليل ، هكذا:

ثم لنضع جدولاً ثانياً يختص بـ "تفاصيل الفواتير" . هكذا:

ولكن ، كيف سنربط التفصيل بفاتورته ؟

جدول رؤوس الفواتير ، كل سطر فيه يعبر عن فاتورة ، و هو مليئ بالفواتير (الأسطر) . و جدول تفاصيل الفواتير ، كل سطر فيه يعبر عن تفصيلة واحدة (قلم) تتبع لفاتورة واحدة . كيف سيتم هذا التتبيع ؟

هكذا:

أضفنا حقل "رقم الفاتورة" ، حتى نوثق أن الأقلام الثلاثة المذكورة تتبع للفاتورة التي رقمها 159.

ألا يسمى هذا تكراراً ؟ ألم يتم تكرار رقم الفاتورة لكل الأقلام ؟ نعم ، و لكنه مقبول جداً ، ليس فقط لأنه ضروري ، بل لأنه أقل ما يمكن . نسميه "تكرار حدي".

لننظر مرة أخرى في بيانات الجدولين:

لدينا الآن ثلاثة فواتير ، و سبعة أقلام تتبع لها . المهم هو مراقبة العلاقة التي تربطهما معاً ، و التثب منها.

لنتأمل هذا:

هذه هي القواعد الثلاثة ، الجدوال ، التي بدأنا الحديث عنها ، إلا أننا نراها الآن بطريقة مختلفة ، من وجهة نظر تصميمية بحتة . لا يوجد بينات هنا لأن البيانات ليست مهمة في هذا المعرض.

لننظر مرة أخرى:

جدول الزبائن لم يطرئ عليه أي تغيير ، إلا أن حقل الزبون في جدول الفواتير قد أصبح "رقم الزبون" . و كذلك "رقم المادة" بدلاً عن "المواد" في جدول تفاصيل الفواتير ، و الذي أيضاً تم تغيير أسماء حقوله لتصبح فردية . ثم أن هناك جدولاً جديداً أضيف هو جدول المواد.

لماذا رقم الزبون في جدول الفواتير بدلاً من اسمه؟

وضع رقم الزبون بدلاً من اسمه سيعقد عملية إدخال البيانات في جدول الفواتير . سيتطلب الأمر مراجعة أرقام الزبائن في جدول الزبائن . و نفس الجديث يتكرر لرقم المادة في تفاصيل المواد.

إلا أنه من وجهة نظر تصميمية ، هذه السيئة هي عين الميزة.

نحن نريد ممن يتعامل مع جدول الفواتير أن يكون الزبون المذكور في الفاتورة مسجل أصلاً في جدول الزبائن . كما أن هذا الزبون يجب أن يذكر في الفاتورة بطريقة لا لبس فيها ، بمعنى أنه من غير الممكن أن يكون هناك زبونان في جدول الزبائن يحققان نفس الزبون المذكور في الفاتورة . أي ، لا نريد أن نقول في الفاتورة أن الزبون هو أحمد ، و يكون لدينا ثلاثة زبائن في جدول الزبائن اسمهم أحمد مثلا ً ... استخدام رقم الزبون في الفاتورة هو ضمان لذلك.

و لكن ، لننظر إلى البيانات التالية:

الزبون "ياسر" تم تعليمه باللون الأحمر ، هذا الزبون لم يذكر أبداً في جدول الفواتير ، أي أنه لم يشتر أية فاتورة ... لا ضرر في ذلك ، هذه ليست مشكلة على الإطلاق.

و كذلك الأمر المادة رقم 99 ، "حليب" ، لم تبع و لا مرة ، و لا مشكلة تصميمية في ذلك.

أما الفاتورة رقم 915 ، فهي تشير إلى زبون رقمه 999 ، و أما تفاصيل الفواتير الملونة بالأحمر ، فهي تشير إلى تبعيتها لفاتورة رقمها 160 غير موجودة أصلا في جدول الفواتير ، أما السطر الأخير الظاهر في تفاصيل الفواتير فهى يحوي المادة رقم 26 ... و التي على ما يبدو محذوفة من جدول المواد !

هناك خلل في البيانات . نقول: خلل في تكامل البيانات ، Data Integration Error ، لماذا كلمة تكامل؟ لأن معلومات الفاتورة لا تكتمل إلا بالعودة للجداول الأخرى ، و كذلك معلومات تفاصيل الفواتير ، و كل الجدوال الأخرى . العلاقة بين هذه الجداول هي في الحقيقة علاقة تكامل.

كيف حدثت هذه المشاكل؟

1.       الإدخال الخاطئ
عندما قام صاحبنا المسؤول عن جدول رؤوس الفواتير بإدخال الفاتورة رقم 915 ، لم ينتبه إلى أن رقم الزبون غير موجود أصلاً في جدول الزبائن.

2.      حذف البيانات
كان هناك زبون رقمه 915 في جدول الزبائن ، إلا أن صاحبنا المسؤول عن هذا الدرج قام بحذف الزبون دون الرجوع إلى جدول الفواتير ، و التحقق فيما إذا كان مستخدماً ...

3.      تعديل البيانات
قام أحدهما بتعديل رقم الزبون بعد أن كان صحيحاً . هذا التعديل تم دون مراقبة.

إذا تخيلنا أنه لا يوجد علم قواعد بيانات ولا حواسب و لا معلوماتية ، و أن هذه الجداول هي بالواقع أدراج تحتوي على بطاقات ، و كل درج مسؤول عنه شخص ، لنا أن نتخيل المشكلة ، و درجة تعرض البيانات للمشكلة.

علم قواعد البيانات ، يضع قاعدةً ، شرطاً ، يكفل "استحالة" حدوث هذه المشكلة . اسم هذا الشرط هو "شرط التكامل المرجعي" ، أو ما يعرف بالـ Referential Integrity.

01 - Database Design Concepts

بسم الله الرحمن الرحيم

مطلوب إعداد جدول لزبائن الشركة .

هذا مثلاً:

لدينا مجموعة من الأشخاص تم إحصاء بيانات عنها ، الاسم و التولد و المدينة و الهاتف ، و هناك مسلسل لضبطها أو لترميزها.

كل سطر في هذا الجدول يمثل وحدة متماسكة . كل سطر هو زبون . محمود رقمه ثلاثة ، من مواليد حمص سنة 1980 ، و هاتفه 345678 . إذن ، في جدول الزبائن ، كل سطر يمثل زبون . من وجهة نظر الجدول ، السطر هو وحدة بنائه ، و لا معنى للقراءة بشكل قطري مثلاً ، المعلومات موجودة أساساً بشكل أفقي .

و من وجهة نظر الجدول ، العامود هو صفة من صفات وحدة بنائه.

أي أن الاسم هو صفة من مواصفات الزبون ، و كذلك التولد و المدينة و الهاتف . نقول: لتوصيف الزبون ، نحن بحاجة لذكر رقمه و اسمه و تولده ، و هكذا . نسمي أسطر الجدول: سجلات ، Records . و نسمي أعمدة الجدول: حقول ، Fields.

الخلاصة:

كل سطر في جدول الزبائن هو زبون . السطر هو وحدة بناء الجدول . نسمي السطر: سجل.

كل عمود في جدول الزبائن هو صفة من صفات الزبون . نسمي العامود: حقل.

كل سطر في جدول الفواتير هو فاتورة ، و كل عامود هو صفة من صفات الفاتورة ، مثلاً رقمها و تاريخها و زبونها و قيمتها الإجمالية ، و هكذا ...

كل سطر في جدول نتائج الامتحانات هو نتيجة امتحان ، الأعمدة هي مثلا ً اسم المادة و اسم الطالب و الفصل الامتحاني و العلامة ، و هكذا ...

اسماء الجداول عادةً ما تكون بصيغة الجمع ، الأسطر هي المفرد من هذه الاسماء . كل سطر في جدول "الزبائن" هو "زبون" ، و كل سطر في جدول "نتائج الامتحانات" هو "نتيجة امتحان".

مجوعة الحقول الموجودة في الجدول هي القاعدة التي بني عليها الجدول ، الأسطر هي البيانات.

لماذا سميت "القاعدة" ؟

لأنها الأساس الذي ستوضع في البيانات.

لأن مجموعة الحقول هي القاعدة التي ستوضع عليها السجلات.

كي نضيف زبون إلى جدول الزبائن ، يجب أن نتقيد بالقاعدة التالية: توفر البيانات رقمه و اسمه و تولده و مدينته و هاتفه . قاعدة.

إذا قلنا "باب المدرسة" فالقصد هو الباب ، المضاف . المصطلح الشهير الذي نعرفه هو "قاعدة البيانات" أو "قواعد البيانات" . المضاف هو "القاعدة" . لماذا كل هذا الاهتمام بالـ "قاعدة" ؟ أليست "البيانات" هي الأهم ؟

في الثمانينات ، قامت وزارة الداخلية في دمشق بالإشراف على مشروع إحصاء سكان سوريا ، جندت عشرات آلاف الموظفين الحكوميين ، و زودتهم ببطاقات تعريف ، و نماذج ، و نظمت توزعهم على المحافظات و المدن و الأحياء . يطرق الموظف باب المنزل ، و يسأل عن سكانه ، و يحصي بيانات عنهم ، يعبئها في نموذج ، و يسلم هذه النماذج في آخر النهار للهيئة المشرفة عليه ، لتقوم بإدخالها في "قاعدة بيانات" عن سكان سوريا . بعد عدة أشهر ، طاولت السنة ، انتهى المشروع . الجدول جاهز . جاهز كي تقوم الجهات المعنية بدراساتها عليه.

لنتخيل هذا الحوار الذي جرى بين مدير المشروع ، و صاحب القرار:

- مدير المشروع: تفضل يا سيدي.

- صاحب القرار: الله يعطيكم العافية ... ممم ، كم شخص لدينا في سوريا؟

- 16 مليون.

- ممم ، ما شاء الله . كم شخص في حلب ؟

- ... في الحقيقة المعلومة موجودة لدينا ، إلا أننا بحاجة للقيام بعملية إحصائية كي نجيب ... سنوافيك بها بأقرب وقت.

- حسناً ، كم شخص في سوريا زمرة دمهم B سلبي ؟

- ... !!!!!!!

- ماذا ؟

- لا نعرف ...

- كيف لا تعرف ؟ ألم تسألوا الناس عن زمر دمهم ؟

- لا ... النماذج التي قمنا بتعبئتها لا تحوي زمزة الدم ...

- ... ، كم شخص في سوريا حاصل على شهادة دكتوراه ؟

- ... لا نعرف L ، لم نسأل عن هذه المعلومة ...

- لماذا لم تسألوا عن هذه المعلومة؟

- يا سيدي ، عندما طلبت منا إحصاء سكان سوريا ، لم تقل لنا أنك تريد أن تعرف زمرة دمهم ، أو شهاداتهم الدراسية ...

- لا لا لا ، هذا غير مقبول ، الله يرضى عليك بتروح بتجبلي هالمعلومتين و بترجع ...

ماذا حصل ؟ هناك بيانات ناقصة . ناقصة من وجهة نظر صاحب القرار . صاحب القرار هو شخص يريد أن يستثمر البيانات ، و ذلك بطرح أسئلة منطقية . نقصد بـ "الأسئلة المنطقية" أسئلة ليست تعجيزية ، جوابها موجود في البيانات ، قد يحتاج الأمر لوقت ، إلا أن الجواب موجود بالتأكيد . السؤال عن عدد سكان حلب سؤال منطقي ، حيث أن "المحافظة" هي معلومة موجودة في كل نموذج تم تعبئته لكل شخص . أما السؤال عن زمرة الدم ، فهو سؤال "تعجيزي" ، مستحيل ، هذه المعلومة غير موجودة في النماذج ، غير موجودة في الجدول.

المشكلة هي أن القاعدة التي بين عليها جدول "السكان" لم تحو حقلاً لـ "زمرة الدم" ، و لا "الشهادة الدراسية" . و الطلب الذي وصى به صاحب القرار بأن "الله يرضى عليك بتروح بتجبلي هالمعلومتين و بترجع ..." ، فهو كارثة ... كارثة بمعنى الكلمة . القاعدة ناقصة. 

كيف حصل هذا الخطأ ؟ و من هو المسؤول عنه.في البداية ، صاحب القرار كانت لديه فكرة عن إحصاء سكان سوريا ، أسند ذلك لمدير المشروع . مدير المشروع قام بدراسة مستفيضة ، بدأ بأن سأل صاحب القرار:ما الهدف من هذا المشروع ؟ و ما هي المعلومات التي تريد أن تعرفها عن سكان سوريا ؟ الجواب أتاه واضحاً ، فقام بوضع "قاعدة" لتجميع بيانات سكان سوريا ، هذه القاعدة تحولت إلى نموذج ، كل نموذج يمثل فرداً في سوريا . تمت مراجعة النموذج (أو سمه الجدول ، أو القاعدة) ، تم طرح الأسئلة المعتمدة على هذا الجدول ، و تم التحقق من إمكانية الإجابة ، ثم تم اعتماد النموذج ، تم تثبيت القاعدة.

ثم ماذا ؟

بعد الانتهاء من مرحلة "التصميم" ، تصميم القاعدة ، بدأت مرحلة "إدخال البيانات" ، و أنشئت الهيئات التنظيمية لإدارة هذه المرحلة ، الخطيرة ، التي انتشرت ، و عبأت النماذج ، و عادت بها إلى مقراتها ، ثم أدخلت النماذج في القاعدة (سجلات في الجدول) ، و انتهت مرحلة "إدخال البيانات".

ثم ماذا ؟

عدنا لمدير المشروع ، تناول الجدول ، تناول بيانات الجدول ، و أسرع إلى صاحب القرار . صاحب القرار سأل الأسئلة المتوقعة ، ثم فاجأ الجميع بأسئلة "تعجيزية" . أسئلة من غير الممكن الإجابة عنها . القاعدة غير مصممة للإجابة عنها.

من يتحمل الخطأ ؟

هناك سجال قديم في هذا المكان ، بين قدرة مدير المشروع ("مصمم القاعدة") ، عندما كان في المرحلة الأولى ، مرحلة تصميم القاعدة ، قدرته على استقراء و توقع الأسئلة التي لم تسأل ، و اقتراح القاعدة أكبر و أشمل مما هو مطلوب من صاحب القرار ، و بين عدم أحقية صاحب القرار بطرحه لأسئلة لم يتم الاتفاق سلفاً عليها ... 

الذي يهمنا هنا هو "المضاف" . قاعدة البيانات . خطورة قاعدة الييانات . القاعدة هي الأساس لنجاح أو فشل أي قاعدة بيانات . مصطلح النجاح و الفشل في هذا المقام نقصد به جدوي المشروع . ما الفائدة من إنشاء قاعدة كتلك لا تفيد في الإجابة عن الأسئلة ؟ بالذات أنه مع معظم الأحوال (أقصد عملياً على أرض الواقع) تتحول هذه الأسئلة التعجيزية في النهاية إلى أسئلة مصيرية من وجهت نظر صاحب القرار ...

القاعدة هي الأساس.

لا بد من تقنين المسألة.

لا بد من وجود "قاعدة" لتصميم قواعد البيانات . في الواقع ليست قاعدة واحدة . هناك أربعة مدراس ، قدمت نظرياتها و أدواتها الخاصة ، كأصول لـ "تحليل" و "تصميم" قواعد البيانات.

gMap

What is the gMap?

The gMap is a Tracking System that incorporates GIS, GPS, GPRS and Google Maps technologies, to provide the live locations of the tracked persons or vehicle; graphically over a map.

Practical Scenario

At the Head Quarters (HQ), the Fleet Manager is using gMap’s main screen, and the Spatials’ Tree (on the right) to put the spatial data, and fill out properties.By doing so, he is filling the system with data, and graphically assigning the location of a Grocery shop, as seen in picture 1:

Picture 1

The map he’s using is an offline map, downloaded from an elevation of 1000 meters, up to 120KM.Not only he can put locations on the map, but he can also draw lines (Polylines), and shapes (Polygons), and control the various format of the shapes, which in this case, represents a marketing zone, as in picture 2:

Picture 2

To organize the data, the marketing team will establish a database for their targeted customers. This will include custom data fields (Attributes) that are designed and assigned for each and every group of customers. As shown in the Picture 3 example, the team has categorized 4 attributes in the "Property Page" of the "Groceries Folder":

Picture 3

The next step would be for the marketing team to detail the data of each and every client (grocery shop) in the "Groceries Folder", as shown in picture 4.

Picture 4

(Please notice the grocery shop in Picture 4, and compare it to the “Groceries Folder” present in the tree in Picture 1)Any data relating to the grocery shop should be attached to the shop's record. For example:- Pictures taken for the shop and products stands by the field marketers.- agreements with the owner plotting marketing strategies and targets.See Picture 5:

Picture 5

Now the marketing manager will start to specify plans for his team. These plans involve places they have to visit and time schedules they have to meet, as seen in picture 6 and 7.So he will go to the “Plans Root” in the tree (Bottom right of image 6), and create the plan:

Picture 6

And he’ll specify the time schedule for that plan (Picture 7):

Picture 7

Now, for the GPS Devices:Starting with a fact that each marketer (individual to be tracked) will be holding a mobile device that contains a GPS receiver, this is what the Fleet Manager will do to track down his men:First of all, he’ll start creating devices entries from the “GPS Devices Root”, as seen in picture 8:

Picture 8

Starting with his first marketer, he goes to the “Technical Data” page to enter the specifications of the GPS Device held by the marketer, as seen in picture 9:

Picture 9

Then back to the Tree, so that he’ll assign the designated plan to the marketer, as seen in picture 10:

Picture 10

Now, back again to the GPS Device, where the Manager will start specifying how will the GPS Device, and the GPS Device Holder (the marketer) will act, and how will he be monitored, and when should the Alert System; alerts the manager. So, the manager will start putting rules, as in picture 11:

Picture 11

The final phase will imply connecting the GPS Device to the Managers’ PC, and programming (uploading) it with the assigned tasks, and alerts, as in picture 12:

Picture 12

The GPS Device has launched off with its holder (the marketer in our case), now we need to track it!As the system goes live, the Manager at the HQ will focus on the GPS Device of his target, and opens the Control Panel of the live GPS Device, as in picture 13. So he will see current Speed, Battery level, GSM Network coverage, a Compass showing the Bearings, GPS Satellites coverage, and other low-level GPS information.

Picture 13

And as the live GPS device travels, it collects GPS data, and sends it to the HQ at the specified pace. A track is plotted on the map, as seen in picture 14:

Picture 14

Statics are available for the track, as in picture 15:

Picture 15

In the HQ, they start needing more and more control, so they start to set up an Operation Room, starting with a print out of the map. But at what sizes, and what zoom levels, and on what paper size should it be printed? No problem… Any paper size will do, and any map size will fit!The manager will start on the “Print Surfaces Root”, and draw a frame from the zoom level of comfort, then opens the properties to specify the Printer and Paper Size, to have the number of rows and columns of paper he needs to generate the Paper Matrix required for printing the Print Surface, as seen in picture 16:

Picture 16

And on the paper size of his choice, the Print Surface will be printed with a dead margin on the right and bottom on each paper in the matrix, so that it can be glued together to form the whole picture, in picture 17:

Picture 17

Why not integrate spatial data with the Back Office suite of your choice?Why not be able to see your customers on the map according to their debits? Or their withdrawal of a certain stock material?Or see those two neighboring customers, with less than 200 meters apart, and more than 60% sale differences?This is all done using a built-in capability in the gMap, that renders the spatial data connected to their Back-Office counter parts: Accounting and Stock Management Packages.The gMap has a XML Driver layer that enables it to link to virtually any MS-SQLServer based databases, and collect data to be reflected, and queried, on the map.(Currently: an XML Driver is available to link with Al-Ameen System). Shown in picture 18 is the “Financial Systems Root”:

Picture 18

Immediately after a link with your back office application is established, you can import directly accounts from the accounting system, to the gMap.And with a drag drop from the tree to the map, you’ll have your accounts situated on the map at their locations. Open an account property page, and witness some financial statistics driven from your back office right into the gMap, as seen in picture 19:

Picture 19

Or dictate your query parameters, and let the gMap query your back office for data, and plot it on the map, as seen in picture 20:

Picture 20

What else?

A. Seeds of a Navigational System:

Picture 21

B. “Public Root” contents dynamically downloaded from a web site:

Picture 22

C. Import & Export of Shape Files (ESRI), KML and KMZ (Google)System Layout?GPS Satellites -> PDAs -> GPRS Network -> gMap Web-Service -> gMap

Picture 23

Implementations

· Marketing & Sales Planning Systems
· Fleet Management Systems
· Security Systems
· Community Development
· Real Estate Planning and Development
· Transportation and Traffic Planning
· Operation Theaters: Internal Affairs, Defense, VIP Security…

Future

· Navigational System
· Dedicated Add-On Tools: Electricity, Water, Oil, Traffic (Railroads), Demography …
· Coherency with International Standards of GIS and CAD: Import/Export
· Multi-Lingual User Interface
· Deep GIS Capabilities

Technical Specifications

· Programming Language: C#
· Database Engine: MS-SQLServer
· OS: Windows XP, Vista, Server 2003
· GPS Devices: NMEA Compliant, Windows Mobile or above
· Full Arabic User Interface.


Developed and Owned By EYAD AL AKHRAS, Damascus, Syria.