Diffstat (limited to 'development/pim/dbpaper/rel.tex') (more/less context) (ignore whitespace changes)
-rw-r--r-- | development/pim/dbpaper/rel.tex | 81 |
1 files changed, 81 insertions, 0 deletions
diff --git a/development/pim/dbpaper/rel.tex b/development/pim/dbpaper/rel.tex new file mode 100644 index 0000000..b7d0990 --- a/dev/null +++ b/development/pim/dbpaper/rel.tex | |||
@@ -0,0 +1,81 @@ | |||
1 | |||
2 | \pagebreak | ||
3 | |||
4 | \subsection{Database Relations} | ||
5 | TODOLIST \{ UID, DueDate, StartDate, EndDate, Completed, Description, Summary, Priority, Progress, Parent, Status \}\\ | ||
6 | DueDate can be null \\ | ||
7 | StartDate and EndDate are for timetracking reasons. | ||
8 | \\ | ||
9 | \\ | ||
10 | \noindent | ||
11 | DATEBOOK \{ UID, ID, Item, Value \}\\ | ||
12 | ID autoincrement\\ | ||
13 | Type element \{ Description, Location, Type, start, end, note, created \}\\ | ||
14 | \\ | ||
15 | \noindent | ||
16 | RECURRANCE \{ UID, TID, RType, RWeekDays, RPosition, RFreq, RHasEndDate, REndDate \} \\ | ||
17 | The TID (TableID) is needed here, since both, TODOLIST and DATEBOOK use it, and in future maybe more.\\ | ||
18 | \\ | ||
19 | \noindent | ||
20 | ADDRESSBOOK \{UID, ID, Item, Value \}\\ | ||
21 | ID autoincrement\\ | ||
22 | For contact to a person:\\ | ||
23 | Type element \{Title, FirstName, MiddleName, LastName, Suffix, Note \}\\ | ||
24 | For contact to a company:\\ | ||
25 | Type element \{ CompanyName, Department, Note \}\\ | ||
26 | \\ | ||
27 | \noindent | ||
28 | POSTAL \{ UID, TID, Type, Street, City, State, Zip, Country \} \\ | ||
29 | where Type can be Home, Business as predefined or any other as custom fields (not syncable) \\ | ||
30 | \\ | ||
31 | \noindent | ||
32 | PERSONAL\_DATA \{ UID, ID, Item, Value \}\\ | ||
33 | ID autoincrement \\ | ||
34 | Item element \{ Company, JobTitle, Department, Office, Profession, Assistant | ||
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, \\ | ||
36 | DefaultEmail, Email, HomeWebpage, Homephone, HomeFax, HomeMobil \}\\ | ||
37 | \\ | ||
38 | \noindent | ||
39 | TABLEID \{ TID, Name, DefaultRep, Version \} \\ | ||
40 | TID Autoincrement \\ | ||
41 | The first 3 TIDs are set: 0 == datebook, 1 == addressbook, 2 == todolist.\\ | ||
42 | The rest can are assigned in order of registration of the service/app. | ||
43 | DefaultRep is the default representation. That are fields from the table of the app itself which should be shown when crosslinked. \\ | ||
44 | \\ | ||
45 | \noindent | ||
46 | CROSSREF \{ TID1, UID1, Item1, TID2, UID2, Item2 \}\\ | ||
47 | Item \emph{x} defines the field-type in the table which should be addressed. It may be empty if no special field should be addressed. \\ | ||
48 | Maybe add a field ``discription'' like ``verwaltet'', ``schaut an'' | ||
49 | |||
50 | \noindent | ||
51 | Thus, 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 | ||
54 | Using ``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 | ||
57 | Still 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...\\ | ||
58 | \\ | ||
59 | \noindent | ||
60 | ALARM \{ TID, UID, Sound, Day, Month, Year, Time \}\\ | ||
61 | TID is needed since more then one app can have alarms and UID is not necessarly unique over different apps. \\ | ||
62 | A exclusive table for all alarms\\ | ||
63 | \\ | ||
64 | \noindent | ||
65 | CATEGORY \{ UID, Parent, Name, ApplicationName, ForeGroundColor, BackGroundColor \}\\ | ||
66 | UID due to making syncing sane\\ | ||
67 | Parent is used for subcategories \\ | ||
68 | \\ | ||
69 | \noindent | ||
70 | RECORD\_CATEGORIES \{ TID, UID, CategoryUID \}\\ | ||
71 | \\ | ||
72 | \noindent | ||
73 | FILES \{ UID, Type, Url \}\\ | ||
74 | \\ | ||
75 | \noindent | ||
76 | APPLICATION \{ UID, TYPE, URL \}\\ | ||
77 | \\ | ||
78 | \noindent | ||
79 | LOCATION \{ UID, Name\}\\ | ||
80 | |||
81 | |||