summaryrefslogtreecommitdiff
path: root/development/pim/dbpaper/intro.tex
authorharlekin <harlekin>2002-09-16 19:45:19 (UTC)
committer harlekin <harlekin>2002-09-16 19:45:19 (UTC)
commit154ef04f6d74044a750ec89c14f3521b0602e795 (patch) (unidiff)
tree7db23061f91861a275beb06772e6864682a660ff /development/pim/dbpaper/intro.tex
parent3a8345528bc39a57b5d5bb50f4a69e32eae6d223 (diff)
downloadopie-154ef04f6d74044a750ec89c14f3521b0602e795.zip
opie-154ef04f6d74044a750ec89c14f3521b0602e795.tar.gz
opie-154ef04f6d74044a750ec89c14f3521b0602e795.tar.bz2
pre draft of the db layout
Diffstat (limited to 'development/pim/dbpaper/intro.tex') (more/less context) (ignore whitespace changes)
-rw-r--r--development/pim/dbpaper/intro.tex112
1 files changed, 112 insertions, 0 deletions
diff --git a/development/pim/dbpaper/intro.tex b/development/pim/dbpaper/intro.tex
new file mode 100644
index 0000000..0a26b90
--- a/dev/null
+++ b/development/pim/dbpaper/intro.tex
@@ -0,0 +1,112 @@
1\pagebreak
2\section{Introduction}
3
4\subsection{This document}
5
6Note: This paper is just a request for comment! Don't expect to find anything in the real implementation !
7\\
8This draft paper describes the database layout of the Opie PIM applications.
9Design goal is a fast and extendable layout on a sql database to support cross referencing.
10
11
12\subsection{Copyright}
13
14Copyright notice
15\copyright 2002, Maximilian Rei{\ss} \& Stefan Eilers \& Holger Freyther
16
17\pagebreak
18\section{Relations}
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.
21Some of the tables are just using 4 attributes:
22\begin{enumerate}
23\item UID: This countains an unique ID for the complete entry.
24\item ID: This defines a number to seperate the rows of an entry.
25\item Type: Describes the type of this entry.
26\item Value: And the data which was described by ``Type'' is stored here.
27\end{enumerate}
28
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:
30The ``Type'' has just to be converted into an ``attribute'' in a XML-tag. Thats all, and that will work for all future Types !
31
32Let's see how such an entry may look like for the table ``ADDRESSBOOK'':
33
34\begin{tabular}[ht]{|l|l|l|l|}
35\hline
36\underline{UID} & \underline{ID} & Type & Value\\
37\hline
38 1231& 00& Title& Herr\\
39\hline
40 1231& 01& FirstName& Stefan\\
41\hline
42 1231& 02& LastName& Eilers\\
43\hline
44\end{tabular}
45\\
46\\
47We need some additional information about this entry, which is stored into the table ``PERSONAL\_DATA\_CONTACT'':
48\\
49\\
50\begin{tabular}[ht]{|l|l|l|l|}
51\hline
52\underline{UID} & \underline{ID} & Type & Value\\
53\hline
54 2345& 00& Email& eilers@sra.uni-hannover.de, eilers.stefan@epost.de\\
55\hline
56 2345& 01& DefaultEmail& eilers@sra.uni-hannover.de\\
57\hline
58 2345& 02& HomeWebPage& www.sra.uni-hannover.de/$\sim$eilers/\\
59\hline
60\end{tabular}
61\\
62\\
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''!}:
64\\
65\\
66\begin{tabular}[ht]{|l|l|l|l|l|l|}
67\hline
68\underline{TID1} & \underline{UID1} & \underline{Type1} & \underline{TID2} & \underline{UID2} & \underline{Type2} \\
69\hline
70 01& 1231& & 03& 2345&\\
71\hline
72\end{tabular}
73\\
74\\
75Type was left empty, due to the fact that we wanted to link the complete entry and not some rows of the entry.
76\\
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 ?
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''!}\\
79\\
80\begin{tabular}[ht]{|l|l|l|l|}
81\hline
82\underline{UID} & \underline{ID} & Type & Value\\
83\hline
84 2344& 11& Children& Amaly, Karl, Clarissa\\
85\hline
86\end{tabular}\\
87\\
88and reference it again with the table ``ADDRESSBOOK'':\\
89\\
90\begin{tabular}[ht]{|l|l|l|l|l|l|}
91\hline
92\underline{TID1} & \underline{UID1} & \underline{Type1} & \underline{TID2} & \underline{UID2} & \underline{Type2} \\
93\hline
94 01& 1231& & 05& 2344&\\
95\hline
96\end{tabular}
97\\
98\\
99But what happens if you want to store additional information about the children, as there mobile phone numbers, etc?
100
101In 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:\\
102\\
103\begin{tabular}[ht]{|l|l|l|l|l|l|}
104\hline
105\underline{TID1} & \underline{UID1} & \underline{Type1} & \underline{TID2} & \underline{UID2} & \underline{Type2} \\
106\hline
107 05& 2344& Children& 01& 9213& \\
108\hline
109 05& 2344& Children& 01& 7654& \\
110\hline
111\end{tabular}
112\\