שילוב SQL & Keywords ממילות-חיפוש לטפסי-חיפוש מוטי פורת

From Keywords To Search Forms

מטרת - העל חיפוש במידע מובנה.

סכמה לדוגמא - DBLife persontopicpublication organization conference related_topic write_pub related_personco_author related_organization give_org_talk give_conf_talk give_tutorial serve_conf

חיפוש במידע מובנה למה לא לשפוך הכל לקובץ טקסט? כדי לנצל את המבניות בזמן השאילתא (תנאים על שדות). כדי לראות את המבניות בתוצאות (לראות ישויות).

עוד מטרה : 100% recall בגוגל מחפשים בשביל מטרה מסוימת, לכן מספיק לקבל מעט דפים טובים. אצלנו המשתמש שואל מגוון של שאלות על הנתונים. לכן רוצים למצוא את כל המופעים של מילות החיפוש. (אולי עם aggregate). אנו מחפשים מעל מסד נתונים נתון. כלומר, המטרה היא כמו של SQL, אך תוך נסיון להקל את הפעולה למשתמש הפשוט.

סיפור אישי מערכת מידע עם הרבה סוגי ישויות. מסכי חיפוש: חיפוש מהיר: איך? צרוב בקוד...

יתרונות בדרכים הקיימות למה מסך חיפוש (טופס)?  מציג כבר חלק מהפתרון.  מנצל את מבניות המידע. למה מילות חיפוש?  לפעמים יותר קל ומהיר.  יכול לכסות הרבה סוגי ישויות.

מוטיבציה מטרה 1: לנצל את היתרונות של מערכת טפסים. בעיה: במסד עם סכמה מורכבת (עשרות ישויות), מגוון הטפסים הוא עצום. מטרה 2: לאפשר שאילתות אד-הוק. המשתמש אולי לא יודע אילו טפסים וטבלאות קיימים.

הפתרון נחפש טפסים ע"י מילות מפתח! חיפוש מילים התוצאה: רשימת טפסים.

מערכות ומחקרים קיימים מילות חיפוש מעל מסד רלציוני מוצא את הטבלאות עם המילים הרצויות ויודע לעשות join. אבל... איך לשלוף רק את הטיסות שבהן היעד הוא ניו-יורק? age>18? aggregates? אפשרי, אם יודעים שמות שדות. רק טפסים (QBE – Query By Example) יש מעט טפסים במסד ולכן קל לבחור אחד מהם.

תכנון ביצוע שאילתא הצגת התוצאות

הבחנה טריוויאלית טופס הוא שאילתת SQL עם פרמטרים.

החלטה עיצובית לשמור במסד הנתונים את כל הטפסים האפשריים, כאילו "טופס" הוא ישות. מותר שיהיו הרבה טפסים אפשריים – הרי מחפשים ביניהם ע"י מילות חיפוש ולא ידנית. אבל איך "נמציא" טפסים?

שלבי התכנון : אילו טפסים להציע 1. נגדיר תת-שפה של SQL. 2. נבנה שאילתות-שלד – אחת לכל טבלה. 3. "שיפוץ" – הרחבת מגוון השאילתות. 4. בניית הטפסים עצמם ע"י כלי GUI אוטומטי. לטבלת ישות לטבלת קשר ידני, מעלה התלבטויות... אוטומטי פעם בחיים

" שיפוץ " ( הגדלת מגוון השאילתות ): התלבטות 1 עבור כל טבלה, האם להציע טופס אחד עם כל השדות, או מספר טפסים עם מעט שדות בכ"א?  אחד - יותר קל למצוא ברשימת הטפסים  אבל יותר קשה למילוי ע"י משתמש טיפש. בחירת המחברים: אחד.

" שיפוץ ": התלבטות 2 האם להציע טפסים עם מידע צרוב:  יתרון: הטופס ידורג גבוה אם מילות החיפוש יהיו בדיוק אלה.  חסרון: כמות אדירה של טפסים שצריך לשמור מראש ולתחזק. בחירת המחברים: לא.

" שיפוץ ": התלבטות 3 כמה joins בין קשרים להציע: דוגמא: במאגר DBLife יש 9 סוגי קשרים עם person. האם נציע טופס לחיפוש אנשים שגם העבירו הרצאה בכנס מסוים וגם עובדים בארגון מסוים? וגם... בחירת המחברים: join של עד שתי טבלאות קשר.  דוגמא נגדית:

" שיפוץ ": אפשרויות נוספות group & aggregate – על אילו שדות? union, intersection

תכנון ביצוע שאילתא הצגת התוצאות

כללי סמנטיקה (בחיפוש מילים): מימוש: Naïve-ANDNaïve-OR DI-AND DI-OR DIJ ANDOR

Naïve פשוט נחפש במאגר הטפסים את המילים שהמשתמש ביקש. הבעיה: טפסים הם שאילתות SQL; John אינו איבר-סכמה (שם של טבלה או עמודה).  והחלטנו לא לצרוב קבועים מהמידע בתוך השאילתות.

DI-OR צריך להוסיף לשאילתא את שמות הטבלאות כדי שנמצא טפסים שמאפשרים שליפה מהן. לכל מילת חיפוש נמצא את כל שמות הטבלאות שמכילות אותה בתוכנן.

DI-OR Rewrite the user’s query Q into R like so: For each word q i  Q: DataIndex(q i ) returns { : of tuples containing q i } Add q i and all the table-name to R. FormIndex(R, “any”) returns { form-id : of forms containing any word from R } e.g.: john papers vldb john person papers vldb topic publication conference

DI-AND Rewrite the user’s query Q into R like so: For each word q i  Q: DataIndex(q i ) returns { : of tuples containing q i } Add q i and all the table-name to R. FormIndex(R, “all”) returns { form-id : of forms containing all words of R } e.g.: ?

DI-AND Build from the user’s query Q a set of buckets {S i }: For each word q i  Q: DataIndex(q i ) returns { : of tuples containing q i } S i = {q i }  {the table-name} For each combination C=(w 1, …,w n )  S 1  …  S n FormIndex(C, “all”) returns { form-id : of forms containing all words of C } Return all the forms (that is, union of the above).

DI-AND לכל מילת חיפוש נמצא את כל שמות הטבלאות שמכילות אותה בתוכנן. נוסיף את שמות הטבלאות ל"דלי" של המילה. נבצע את כל השאילתות: בתוך כל אחת AND, אבל בין התוצאות שלהן – איחוד. vldb topic publication conference papersjohn person john papers vldb john papers topic john papers publication john papers conference person papers vldb person papers topic person papers publication person papers conference

תזכורת החיפוש מוצא את כל הטפסים שמכילים את המילים. לכן john papers vldb (והחיפוש הנגזר ממנו) יציע למשתמש לא רק את הטופס לחיפוש מאמרים של אנשים, אלא גם טפסים לחיפוש מאמרים של אנשים שהיו בכנס X, מאמרים של אנשים שעובדים בארגון Y וכו'.

DIJ – סילוק טפסים מתים אפשר לסלק מראש טפסים שבוודאות יתנו תוצאה ריקה. אם john מופיע בטבלה person עם pid=12345, אבל בטבלה person_organization אין אף שורה עם pid אלו, אז נפסול את כל הטפסים איתה. בעזרת Data Index תוספת בדיקה לאלגוריתם DI-AND.

DIJ For each word q i  Q: DataIndex(q i ) returns { : of tuples containing q i } S i = {q i }  {the table-name} For each combination C=(w 1, …,w n )  S 1  …  S n FormIndex(C, “all”) returns { form-id : of forms containing all words of C } Return all the forms For each table-name T (from the above set): For each table T2 (in the DB) that has a foreign-key to T: If T2 does not refer to any relevant tuple in T, mark T2 as forbidden. that don’t use forbidden tables. תזכורת: DI-AND

תכנון ביצוע שאילתא הצגת התוצאות

דירוג הטפסים מתייחסים לטפסים (כלומר, שאילתות ה-SQL שבהם) כטקסט, ומדרגים אותם בדרך מקובלת לדירוג טקסט. כל מערכת החיפוש – כולל הדירוג – היא ע"י מנוע Lucene. אין התייחסות לפרטי המידע (כגון כמה רשומות של John כל טופס אמור לשלוף).

קיבוץ הטפסים רשימת הטפסים היא בעצם עץ, שבו מקבצים את הטפסים שנגזרו מאותה שאילתת-שלד. התיאורים הוזנו ידנית בשלב התכנון.

תוצאות

הניסוי משימות נתונות שאילתות שנחקר מסוים כתב

תוצאות של נחקר אחד במאגר יש 196 טפסים = 14 טבלאות * 14 טפסים לכל טבלה

זמני העבודה של המשתמשים ממוצע על כל הקבוצה

תוצאות של קבוצת הנחקרים הדרגה של הטופס הנכון ברשימת הטפסים ושל הקבוצה עם הטופס הנכון, ברשימת הקבוצות.  במקרה הכי טוב, הכי גרוע והחציון

תוצאות עם יותר טפסים במאגר כנ"ל, אך במאגר עם 700 טפסים  שכוללים את כל ה-join-ים בין שלוש טבלאות קשר. כל שאילתא מחזירה בממוצע 27.8% מהטפסים במאגר – בדיוק אותו אחוז כמו עם המאגר הקודם.

שאלות ? יאללה הביתה