-rw-r--r-- | development/pim/dbpaper/intro.tex | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/development/pim/dbpaper/intro.tex b/development/pim/dbpaper/intro.tex index c456333..fd790d7 100644 --- a/development/pim/dbpaper/intro.tex +++ b/development/pim/dbpaper/intro.tex | |||
@@ -1,107 +1,107 @@ | |||
1 | \pagebreak | 1 | \pagebreak |
2 | \section{Introduction} | 2 | \section{Introduction} |
3 | 3 | ||
4 | \subsection{This document} | 4 | \subsection{This document} |
5 | 5 | ||
6 | Note: This paper is just a request for comment! Don't expect to find anything in the real implementation ! | 6 | Note: This paper is just a request for comment! Don't expect to find anything in the real implementation ! |
7 | \\ | 7 | \\ |
8 | This draft paper describes the database layout of the Opie PIM applications. | 8 | This draft paper describes the database layout of the Opie PIM applications. |
9 | Design goal is a fast and extendable layout on a sql database to support cross referencing. | 9 | Design goal is a fast and extendable layout on a sql database to support cross referencing. |
10 | 10 | ||
11 | 11 | ||
12 | \subsection{Copyright} | 12 | \subsection{Copyright} |
13 | 13 | ||
14 | Copyright notice | 14 | Copyright notice |
15 | \copyright 2002, Maximilian Rei{\ss} \& Stefan Eilers \& Holger Freyther | 15 | \copyright 2002-2004, Maximilian Rei{\ss} \& Stefan Eilers \& Holger Freyther |
16 | 16 | ||
17 | \pagebreak | 17 | \pagebreak |
18 | \section{Relations} | 18 | \section{Relations} |
19 | \subsection{About Cross Referencing and Horizontal Data Storage} | 19 | \subsection{About Cross Referencing and Horizontal Data Storage} |
20 | Before you read on, it may be helpful to get some information about the solution of ``horizontal'' data storage into the tables and cross referencing. | 20 | Before you read on, it may be helpful to get some information about the solution of ``horizontal'' data storage into the tables and cross referencing. |
21 | Some of the tables are just using 5 attributes: | 21 | Some of the tables are just using 5 attributes: |
22 | \begin{enumerate} | 22 | \begin{enumerate} |
23 | \item UID: This countains an unique ID for the complete entry. An entry may consist of multiple | 23 | \item UID: This countains an unique ID for the complete entry. An entry may consist of multiple |
24 | rows, seperated by ID. | 24 | rows, seperated by ID. |
25 | \item ID: This defines a number to seperate the rows of an entry. UID + ID must be unique for every entry. | 25 | \item ID: This defines a number to seperate the rows of an entry. UID + ID must be unique for every entry (primary key). |
26 | \item Type: Describes the type of this entry. | 26 | \item Type: Describes the type of this entry. |
27 | \item Priority: For instance: Your default email-address will get the priority 1 and the other 2.. . 0 means ``not defined''. | 27 | \item Priority: For instance: Your default email-address will get the priority 1 and the other 2.. . 0 means ``not defined''. |
28 | \item Value: The data which was described by ``Type'' is stored here. | 28 | \item Value: The data which was described by ``Type'' is stored here. |
29 | \end{enumerate} | 29 | \end{enumerate} |
30 | 30 | ||
31 | These kinds of tables are very flexible in what they may contain, due to the fact that the ``Type'' may be without any constraint. Therefore it is perfectly for storing personal information, which may change in the future, or should be increased. | 31 | These kinds of tables are very flexible in what they may contain, due to the fact that the ``Type'' may be without any constraint. Therefore it is perfectly for storing personal information, which may change in the future, or should be increased. |
32 | \\ | 32 | \\ |
33 | Let's see how such an entry may look like for the table ``ADDRESSBOOK'': | 33 | Let's see how such an entry may look like for the table ``ADDRESSBOOK'': |
34 | 34 | ||
35 | \begin{tabular}[ht]{|l|l|l|l|} | 35 | \begin{tabular}[ht]{|l|l|l|l|} |
36 | \hline | 36 | \hline |
37 | \underline{UID} & \underline{ID} & Type & Value\\ | 37 | \underline{UID} & \underline{ID} & Type & Value\\ |
38 | \hline | 38 | \hline |
39 | 1231& 00& Title& Herr\\ | 39 | 1231& 00& Title& Herr\\ |
40 | \hline | 40 | \hline |
41 | 1231& 01& FirstName& Stefan\\ | 41 | 1231& 01& FirstName& Stefan\\ |
42 | \hline | 42 | \hline |
43 | 1231& 02& LastName& Eilers\\ | 43 | 1231& 02& LastName& Eilers\\ |
44 | \hline | 44 | \hline |
45 | \end{tabular} | 45 | \end{tabular} |
46 | \\ | 46 | \\ |
47 | \\ | 47 | \\ |
48 | We need some additional information about this entry, which is stored into the table ``PERSONAL\_DATA'': | 48 | We need some additional information about this entry, which is stored into the table ``PERSONAL\_DATA'': |
49 | \\ | 49 | \\ |
50 | \\ | 50 | \\ |
51 | \begin{tabular}[ht]{|l|l|l|l|l|} | 51 | \begin{tabular}[ht]{|l|l|l|l|l|} |
52 | \hline | 52 | \hline |
53 | \underline{UID} & \underline{ID} & Type & Priority & Value\\ | 53 | \underline{UID} & \underline{ID} & Type & Priority & Value\\ |
54 | \hline | 54 | \hline |
55 | 2345& 00& Email& 1& eilers.stefan@epost.de\\ | 55 | 2345& 00& Email& 1& eilers.stefan@epost.de\\ |
56 | \hline | 56 | \hline |
57 | 2345& 01& Email& 2& eilers@sra.uni-hannover.de\\ | 57 | 2345& 01& Email& 2& eilers@sra.uni-hannover.de\\ |
58 | \hline | 58 | \hline |
59 | 2345& 02& WebPage& 1& www.sra.uni-hannover.de/$\sim$eilers/\\ | 59 | 2345& 02& WebPage& 1& www.sra.uni-hannover.de/$\sim$eilers/\\ |
60 | \hline | 60 | \hline |
61 | \end{tabular} | 61 | \end{tabular} |
62 | \\ | 62 | \\ |
63 | \\ | 63 | \\ |
64 | The last question is: How to get these information together? This is the job of the cross-referencing-table\footnote{We expecting that the table ``PERSONAL\_DATA'' was registered in the table ``TABLEID'' as table ``03''and ADDRESSBOOK with ``01''!}: | 64 | The last question is: How to get these information together? This is the job of the cross-referencing-table\footnote{We expecting that the table ``PERSONAL\_DATA'' was registered in the table ``TABLEID'' as table ``03''and ADDRESSBOOK with ``01''!}: |
65 | \\ | 65 | \\ |
66 | \\ | 66 | \\ |
67 | \begin{tabular}[ht]{|l|l|l|l|l|l|} | 67 | \begin{tabular}[ht]{|l|l|l|l|l|l|} |
68 | \hline | 68 | \hline |
69 | \underline{TID1} & \underline{UID1} & \underline{ID1} & \underline{TID2} & \underline{UID2} & \underline{ID2} \\ | 69 | \underline{TID1} & \underline{UID1} & \underline{ID1} & \underline{TID2} & \underline{UID2} & \underline{ID2} \\ |
70 | \hline | 70 | \hline |
71 | 01& 1231& (NULL) & 03& 2345& (NULL) \\ | 71 | 01& 1231& (NULL) & 03& 2345& (NULL) \\ |
72 | \hline | 72 | \hline |
73 | \end{tabular} | 73 | \end{tabular} |
74 | \\ | 74 | \\ |
75 | \\ | 75 | \\ |
76 | ID was left empty, due to the fact that we wanted to link the complete entry and not some rows of the entry. | 76 | ID was left empty, due to the fact that we wanted to link the complete entry and not some rows of the entry. |
77 | \\ | 77 | \\ |
78 | In some cases, it may be useful to reference in a much more smaller granularity than complete entries. What should we do, if we want to store the children of a person ? | 78 | In some cases, it may be useful to reference in a much more smaller granularity than complete entries. What should we do, if we want to store the children of a person ? |
79 | The easiest way is to store the children into the table ``PERSONAL\_DATA'':\footnote{We remember that the table ``PERSONAL\_DATA'' was registered in the table ``TABLEID'' as table ``03''!}, too.\\ | 79 | The easiest way is to store the children into the table ``PERSONAL\_DATA'':\footnote{We remember that the table ``PERSONAL\_DATA'' was registered in the table ``TABLEID'' as table ``03''!}, too.\\ |
80 | \\ | 80 | \\ |
81 | \begin{tabular}[ht]{|l|l|l|l|l|} | 81 | \begin{tabular}[ht]{|l|l|l|l|l|} |
82 | \hline | 82 | \hline |
83 | \underline{UID} & \underline{ID} & Type & Priority & Value\\ | 83 | \underline{UID} & \underline{ID} & Type & Priority & Value\\ |
84 | \hline | 84 | \hline |
85 | 2345& 11& Child & 0 & Amaly \\ | 85 | 2345& 11& Child & 0 & Amaly \\ |
86 | \hline | 86 | \hline |
87 | 2345& 12& Child & 0 & Karl \\ | 87 | 2345& 12& Child & 0 & Karl \\ |
88 | \hline | 88 | \hline |
89 | 2345& 13& Child & 0 & Clarissa\\ | 89 | 2345& 13& Child & 0 & Clarissa\\ |
90 | \hline | 90 | \hline |
91 | \end{tabular}\\ | 91 | \end{tabular}\\ |
92 | \\ | 92 | \\ |
93 | 93 | ||
94 | But what happens if you want to store additional information about the children, as there mobile phone numbers, etc? | 94 | But what happens if you want to store additional information about the children, as there mobile phone numbers, etc? |
95 | 95 | ||
96 | In this case we need an entry in addressbook and a reference to this entry. Lets expect ``Amaly'' was stored in the table ``ADDRESSBOOK'' with UID 9213 and Karl with UID 7654. A cross-reference will look like this:\\ | 96 | In this case we need an entry in addressbook and a reference to this entry. Lets expect ``Amaly'' was stored in the table ``ADDRESSBOOK'' with UID 9213 and Karl with UID 7654. A cross-reference will look like this:\\ |
97 | \\ | 97 | \\ |
98 | \begin{tabular}[ht]{|l|l|l|l|l|l|} | 98 | \begin{tabular}[ht]{|l|l|l|l|l|l|} |
99 | \hline | 99 | \hline |
100 | \underline{TID1} & \underline{UID1} & \underline{ID1} & \underline{TID2} & \underline{UID2} & \underline{ID2} \\ | 100 | \underline{TID1} & \underline{UID1} & \underline{ID1} & \underline{TID2} & \underline{UID2} & \underline{ID2} \\ |
101 | \hline | 101 | \hline |
102 | 03& 2345& 11& 01& 9213& (NULL) \\ | 102 | 03& 2345& 11& 01& 9213& (NULL) \\ |
103 | \hline | 103 | \hline |
104 | 03& 2345& 12& 01& 7654& (NULL) \\ | 104 | 03& 2345& 12& 01& 7654& (NULL) \\ |
105 | \hline | 105 | \hline |
106 | \end{tabular} | 106 | \end{tabular} |
107 | \\ | 107 | \\ |