summaryrefslogtreecommitdiff
Unidiff
Diffstat (more/less context) (ignore whitespace changes)
-rw-r--r--development/pim/dbpaper/dbpimpaper.tex1
-rw-r--r--development/pim/dbpaper/intro.tex63
-rw-r--r--development/pim/dbpaper/rel.tex22
-rw-r--r--development/pim/dbpaper/tables.tex23
4 files changed, 50 insertions, 59 deletions
diff --git a/development/pim/dbpaper/dbpimpaper.tex b/development/pim/dbpaper/dbpimpaper.tex
index f664a05..fe060de 100644
--- a/development/pim/dbpaper/dbpimpaper.tex
+++ b/development/pim/dbpaper/dbpimpaper.tex
@@ -37,4 +37,5 @@
370.0.6 & Stefan Eilers & eilers.stefan@epost.de \\ \hline 370.0.6 & Stefan Eilers & eilers.stefan@epost.de \\ \hline
380.0.7 & Maximilian Reiß & harlekin@handhelds.org \\ \hline 380.0.7 & Maximilian Reiß & harlekin@handhelds.org \\ \hline
390.0.8 & Stefan Eilers & eilers.stefan@epost.de \\ \hline
39\end{tabular} 40\end{tabular}
40} 41}
diff --git a/development/pim/dbpaper/intro.tex b/development/pim/dbpaper/intro.tex
index 0a26b90..c456333 100644
--- a/development/pim/dbpaper/intro.tex
+++ b/development/pim/dbpaper/intro.tex
@@ -19,15 +19,16 @@ Copyright notice
19\subsection{About Cross Referencing and Horizontal Data Storage} 19\subsection{About Cross Referencing and Horizontal Data Storage}
20Before you read on, it may be helpful to get some information about the solution of ``horizontal'' data storage into the tables and cross referencing. 20Before you read on, it may be helpful to get some information about the solution of ``horizontal'' data storage into the tables and cross referencing.
21Some of the tables are just using 4 attributes: 21Some 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. 23\item UID: This countains an unique ID for the complete entry. An entry may consist of multiple
24\item ID: This defines a number to seperate the rows of an entry. 24rows, 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 Type: Describes the type of this entry. 26\item Type: Describes the type of this entry.
26\item Value: And the data which was described by ``Type'' is stored here. 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.
27\end{enumerate} 29\end{enumerate}
28 30
29These 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. The other advantage is the fact that these tables are automatically convertable into XML: 31These 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.
30The ``Type'' has just to be converted into an ``attribute'' in a XML-tag. Thats all, and that will work for all future Types ! 32\\
31
32Let's see how such an entry may look like for the table ``ADDRESSBOOK'': 33Let's see how such an entry may look like for the table ``ADDRESSBOOK'':
33 34
@@ -45,56 +46,50 @@ Let's see how such an entry may look like for the table ``ADDRESSBOOK'':
45\\ 46\\
46\\ 47\\
47We need some additional information about this entry, which is stored into the table ``PERSONAL\_DATA\_CONTACT'': 48We need some additional information about this entry, which is stored into the table ``PERSONAL\_DATA'':
48\\ 49\\
49\\ 50\\
50\begin{tabular}[ht]{|l|l|l|l|} 51\begin{tabular}[ht]{|l|l|l|l|l|}
51\hline 52\hline
52\underline{UID} & \underline{ID} & Type & Value\\ 53\underline{UID} & \underline{ID} & Type & Priority & Value\\
53\hline 54\hline
54 2345& 00& Email& eilers@sra.uni-hannover.de, eilers.stefan@epost.de\\ 55 2345& 00& Email& 1& eilers.stefan@epost.de\\
55\hline 56\hline
56 2345& 01& DefaultEmail& eilers@sra.uni-hannover.de\\ 57 2345& 01& Email& 2& eilers@sra.uni-hannover.de\\
57\hline 58\hline
58 2345& 02& HomeWebPage& www.sra.uni-hannover.de/$\sim$eilers/\\ 59 2345& 02& WebPage& 1& www.sra.uni-hannover.de/$\sim$eilers/\\
59\hline 60\hline
60\end{tabular} 61\end{tabular}
61\\ 62\\
62\\ 63\\
63The 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\_CONTACT'' was registered in the table ``TABLEID'' as table ``03''!}: 64The 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\\ 65\\
65\\ 66\\
66\begin{tabular}[ht]{|l|l|l|l|l|l|} 67\begin{tabular}[ht]{|l|l|l|l|l|l|}
67\hline 68\hline
68\underline{TID1} & \underline{UID1} & \underline{Type1} & \underline{TID2} & \underline{UID2} & \underline{Type2} \\ 69\underline{TID1} & \underline{UID1} & \underline{ID1} & \underline{TID2} & \underline{UID2} & \underline{ID2} \\
69\hline 70\hline
70 01& 1231& & 03& 2345&\\ 71 01& 1231& (NULL) & 03& 2345& (NULL) \\
71\hline 72\hline
72\end{tabular} 73\end{tabular}
73\\ 74\\
74\\ 75\\
75Type was left empty, due to the fact that we wanted to link the complete entry and not some rows of the entry. 76ID was left empty, due to the fact that we wanted to link the complete entry and not some rows of the entry.
76\\ 77\\
77In 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 ? 78In 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 ?
78The easiest way is to store the children into the table ``PERSONAL\_DATA'':\footnote{We expecting that the table ``PERSONAL\_DATA'' was registered in the table ``TABLEID'' as table ``05''!}\\ 79The 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\\ 80\\
80\begin{tabular}[ht]{|l|l|l|l|} 81\begin{tabular}[ht]{|l|l|l|l|l|}
81\hline 82\hline
82\underline{UID} & \underline{ID} & Type & Value\\ 83\underline{UID} & \underline{ID} & Type & Priority & Value\\
83\hline 84\hline
84 2344& 11& Children& Amaly, Karl, Clarissa\\ 85 2345& 11& Child & 0 & Amaly \\
85\hline 86\hline
86\end{tabular}\\ 87 2345& 12& Child & 0 & Karl \\
87\\
88and reference it again with the table ``ADDRESSBOOK'':\\
89\\
90\begin{tabular}[ht]{|l|l|l|l|l|l|}
91\hline 88\hline
92\underline{TID1} & \underline{UID1} & \underline{Type1} & \underline{TID2} & \underline{UID2} & \underline{Type2} \\ 89 2345& 13& Child & 0 & Clarissa\\
93\hline 90\hline
94 01& 1231& & 05& 2344&\\ 91\end{tabular}\\
95\hline
96\end{tabular}
97\\
98\\ 92\\
93
99But what happens if you want to store additional information about the children, as there mobile phone numbers, etc? 94But what happens if you want to store additional information about the children, as there mobile phone numbers, etc?
100 95
@@ -103,9 +98,9 @@ In this case we need an entry in addressbook and a reference to this entry. Lets
103\begin{tabular}[ht]{|l|l|l|l|l|l|} 98\begin{tabular}[ht]{|l|l|l|l|l|l|}
104\hline 99\hline
105\underline{TID1} & \underline{UID1} & \underline{Type1} & \underline{TID2} & \underline{UID2} & \underline{Type2} \\ 100\underline{TID1} & \underline{UID1} & \underline{ID1} & \underline{TID2} & \underline{UID2} & \underline{ID2} \\
106\hline 101\hline
107 05& 2344& Children& 01& 9213& \\ 102 03& 2345& 11& 01& 9213& (NULL) \\
108\hline 103\hline
109 05& 2344& Children& 01& 7654& \\ 104 03& 2345& 12& 01& 7654& (NULL) \\
110\hline 105\hline
111\end{tabular} 106\end{tabular}
diff --git a/development/pim/dbpaper/rel.tex b/development/pim/dbpaper/rel.tex
index b7d0990..967155d 100644
--- a/development/pim/dbpaper/rel.tex
+++ b/development/pim/dbpaper/rel.tex
@@ -30,9 +30,9 @@ where Type can be Home, Business as predefined or any other as custom fields (no
30\\ 30\\
31\noindent 31\noindent
32PERSONAL\_DATA \{ UID, ID, Item, Value \}\\ 32PERSONAL\_DATA \{ UID, ID, Type, Priority, Value \}\\
33ID autoincrement \\ 33ID autoincrement \\
34Item element \{ Company, JobTitle, Department, Office, Profession, Assistant 34Type element \{ Personal, Company, University, Birthday, Aniversary, Gender, Child, Jobtitle, Department,
35 \footnote{What is Assistent and Manager ?? (se), and what about multiple assistents? Maybe by same UID but different ID and same Item - ugly(max)}, Manager, Spouse, Children, Gender, Birthday, Aniversary, Nickname, Note, \\ 35Office, Profession, Assistant, Nickname, Spouse, Manager, Note, Email, WebPage, Phone, Fax \}\\
36 DefaultEmail, Email, HomeWebpage, Homephone, HomeFax, HomeMobil \}\\ 36Priority: Highest = 1, Undefined = 0\\
37\\ 37\\
38\noindent 38\noindent
@@ -41,17 +41,11 @@ TID Autoincrement \\
41The first 3 TIDs are set: 0 == datebook, 1 == addressbook, 2 == todolist.\\ 41The first 3 TIDs are set: 0 == datebook, 1 == addressbook, 2 == todolist.\\
42The rest can are assigned in order of registration of the service/app. 42The rest can are assigned in order of registration of the service/app.
43DefaultRep is the default representation. That are fields from the table of the app itself which should be shown when crosslinked. \\ 43DefaultRep is the default representation. That are fields from the table of the app itself which should be shown when crosslinked\footnote{This should be described much more detailed to be clear! (se)}. \\
44\\ 44\\
45\noindent 45\noindent
46CROSSREF \{ TID1, UID1, Item1, TID2, UID2, Item2 \}\\ 46CROSSREF \{ TID1, UID1, ID1, TID2, UID2, ID2 \}\\
47Item \emph{x} defines the field-type in the table which should be addressed. It may be empty if no special field should be addressed. \\ 47ID\emph{x} defines the ``line'' in the table (grouped by UID) which should be linked. It may be empty if no special field should be addressed. \\
48Maybe add a field ``discription'' like ``verwaltet'', ``schaut an'' 48Maybe add a field ``discription'' like ``verwaltet'', ``schaut an''
49 49\\
50\noindent
51Thus, it is possible to crossreference i.e. a Child (Item1 = ``Child'') in the Table PERSONAL\_DATA (TID1 = 0) with an entry in the Table ADDRESSBOOK (TID= 1, Item2 = ````) which stores the data of that child.\\
52
53\noindent
54Using ``Item'' to select which element should be referenced (instead using the ID which may only exist in our table) should guarantee that this reference may survive conversions between different formats. I.e.: For converting our Database into a XML-File, the Item should be converted directly into a attribute-name which is placed into a tag. Therefore the cross reference will stay correct!
55
56\noindent 50\noindent
57Still unclear is, how to synchronize our database (as XML-File, directly or via C++ Interface access) with outlook or other systems, without loosing this cross reference. We could not expect that this fine granularity or referencing may be supported by other systems...\\ 51Still unclear is, how to synchronize our database (as XML-File, directly or via C++ Interface access) with outlook or other systems, without loosing this cross reference. We could not expect that this fine granularity or referencing may be supported by other systems...\\
diff --git a/development/pim/dbpaper/tables.tex b/development/pim/dbpaper/tables.tex
index ac28a47..64ae02d 100644
--- a/development/pim/dbpaper/tables.tex
+++ b/development/pim/dbpaper/tables.tex
@@ -63,5 +63,5 @@ Recurrence:\\
63CREATE TABLE RECURRENCE ( 63CREATE TABLE RECURRENCE (
64 UID int NOT NULL UNIQUE, 64 UID int NOT NULL UNIQUE,
65 TID int NOT NULL 65 TID int NOT NULL
66 RType int, 66 RType int,
67 RWeekDays int, 67 RWeekDays int,
@@ -129,9 +129,10 @@ Personal data: \\
129\end{tabular} 129\end{tabular}
130\begin{verbatim} 130\begin{verbatim}
131CREATE TABLE PERSONAL_DATA_CONTACT ( 131CREATE TABLE PERSONAL_DATA (
132 UID int NOT NULL UNIQUE, 132 UID int NOT NULL UNIQUE,
133 ID int AUTOINCREMENT, 133 ID int AUTOINCREMENT,
134 Ident text, 134 Ident text,
135 Value text, 135 Priority int,
136 Value text,
136 PRIMARY KEY(UID,ID) 137 PRIMARY KEY(UID,ID)
137); 138);
@@ -172,8 +173,8 @@ CREATE TABLE CROSSREF (
172 TID1 int NOT NULL, 173 TID1 int NOT NULL,
173 UID1 int NOT NULL, 174 UID1 int NOT NULL,
174 Item1 int NOT NULL, 175 ID1 int NOT NULL,
175 TID2 int MOT NULL, 176 TID2 int NOT NULL,
176 UID2 int NOT NULL, 177 UID2 int NOT NULL,
177 Item2 int NOT NULL, 178 ID2 int NOT NULL,
178 PRIMARY KEY() 179 PRIMARY KEY()
179); 180);
@@ -195,5 +196,5 @@ CREATE TABLE CATEGORY (
195 Name text, 196 Name text,
196 ApplicationName text, 197 ApplicationName text,
197 ForeGroundColor text,<-- maybe hex? 198 ForeGroundColor text, <-- maybe hex?
198 BackGroundColor text, 199 BackGroundColor text,
199 PRIMARY KEY(UID) 200 PRIMARY KEY(UID)
@@ -238,5 +239,5 @@ CREATE TABLE APPLICATION (
238 239
239\noindent 240\noindent
240 Location: \\ 241Location: \\
241\begin{tabular}[ht]{|l|l|} 242\begin{tabular}[ht]{|l|l|}
242\hline 243\hline