Subversion Repositories computer_asset_manager_v2

Rev

Rev 26 | Show entire file | Ignore whitespace | Details | Blame | Last modification | View Log | RSS feed

Rev 26 Rev 33
Line 27... Line 27...
27
         </tr>
27
         </tr>
28
         <tr>
28
         <tr>
29
            <td valign='top'>_menu</td>
29
            <td valign='top'>_menu</td>
30
            <td valign='top'>describes the menuing system used in the program. This is based on the library DBHierarchialHash (DBMenu extends it). Each entry is a menu, with a (possibly null) parent, a caption, and a URL to go to if the menu item is selected.<br />This is modified by modules, with menu items added when a module is activated</td>
30
            <td valign='top'>describes the menuing system used in the program. This is based on the library DBHierarchialHash (DBMenu extends it). Each entry is a menu, with a (possibly null) parent, a caption, and a URL to go to if the menu item is selected.<br />This is modified by modules, with menu items added when a module is activated</td>
31
         </tr>
31
         </tr>
32
         <tr>
-
 
33
            <td valign='top'>_user</td>
-
 
34
            <td valign='top'>defines access to the program. However, _user entries should never be removed as the can be linked to various modules. Thus, it has two date fields; added_date and removed_date to allow removal from access while maintaining structual integrity.</td>
-
 
35
         </tr>
-
 
36
      </table>
32
      </table>
37
      <p>
33
      <p>
38
         The remaining tables should never have rows deleted under normal circumstances, in or to track history and/or maintain data integrity. They have two additional date fields, added_date and removed_date. An edit of any of these tables proceeds as follows:
34
         The remaining tables should never have rows deleted under normal circumstances, in or to track history and/or maintain data integrity. They have two additional date fields, added_date and removed_date. An edit of any of these tables proceeds as follows:
39
         mark "deleted" row with removed_date = a non-null value
35
         mark "deleted" row with removed_date = a non-null value
40
         copy the newly removed row's data to new row, modifying the fields necessary (added_date always)
36
         copy the newly removed row's data to new row, modifying the fields necessary (added_date always)
Line 82... Line 78...
82
      </p>
78
      </p>
83
      <p>
79
      <p>
84
         A device also has one child table, device_type. device_type allows us to categorize devices by function; router, server, workstation, virtual. This relationship does not involve link tables; one of the columns in device is device_type_id, so a device can only have one type.
80
         A device also has one child table, device_type. device_type allows us to categorize devices by function; router, server, workstation, virtual. This relationship does not involve link tables; one of the columns in device is device_type_id, so a device can only have one type.
85
      </p>
81
      </p>
86
      <p>
82
      <p>
87
         Finally, there is one weird table, alias. I found computer names change over a period of time, and there can actually be multiple names for a device at the same time, especially when automated reporting is done.
83
         Device has three additional fields for unique identification:
-
 
84
         <table border='1'>
-
 
85
            <tr><th>Name</th><th>Definition</th><th>Notes</th></tr>
-
 
86
            <tr>
-
 
87
               <td>uuid</td>
-
 
88
               <td>varchar(32)</td>
-
 
89
               <td>UUID of the machine, if available</td>
88
      </p>
90
            </tr>
89
      <p>
91
            <tr>
-
 
92
               <td>serial</td>
-
 
93
               <td>varchar(32)</td>
90
         alias is not a true relational table. Instead, it tracks aliases for devices, sites or clients, depending on the source column; a 64 varchar which is designed to store the table name it is aliasing. This is a kludge to solve a problem that exists in real life, but has no elegant solution in a DBMS.
94
               <td>Manufacturer's Serial Number of machine, if available</td>
91
      </p>
95
            </tr>
92
      <p>
96
            <tr>
-
 
97
               <td>name</td>
-
 
98
               <td>varchar(64)</td>
93
         See database.png for a diagram of the basic database.
99
               <td>Name of machine (can change)</td>
94
      </p>
100
            </tr>
95
      <p>
101
         </table>
96
         IMPORTANT: This document describes the actual database layout. However, CAMP does not read the layout from the database. Instead, it uses a hash to describe the database and some PHP classes that automate a lot of the screens. After the database is defined, the hash must be created. See DatabaseDefinition.php in the include directory.
102
         These are arbitrary, but the combination should uniquely determine any entry. This is designed to allow automated processes to locate a specific machine, and to allow export/import of data in a consistent manner. While UUID may be enough by itself, it is not always unique, even amongst server class machines. All of these may be null except name. NOTE: name can be changed. Internally, devices are identified by the key field, device_id.
97
      </p>
103
      </p>
98
      <table border='1'>
104
      <table border='1'>
99
         <tr>
105
         <tr>
100
            <th>
106
            <th>
101
               Table
107
               Table
Line 107... Line 113...
107
         <tr>
113
         <tr>
108
            <td valign='top'>
114
            <td valign='top'>
109
               device
115
               device
110
            </td>
116
            </td>
111
            <td valign='top'>
117
            <td valign='top'>
112
               Holds some basic information about a device; name, device_type and any notes you may want
118
               Holds some basic information about a device; name, device_type, uuid and/or serial number
113
            </td>
119
            </td>
114
         </tr>
120
         </tr>
115
         <tr>
121
         <tr>
116
            <td valign='top'>
122
            <td valign='top'>
117
               client
123
               client
118
            </td>
124
            </td>
119
            <td valign='top'>
125
            <td valign='top'>
120
               Holds information about a particular client, such as name, notes, and private notes which are available to limited visitors
126
               Holds the name of particular client (ownership)
121
            </td>
127
            </td>
122
         </tr>
128
         </tr>
123
         <tr>
129
         <tr>
124
            <td valign='top'>
130
            <td valign='top'>
125
               site
131
               site
126
            </td>
132
            </td>
127
            <td valign='top'>
133
            <td valign='top'>
128
               Physical sites which may house devices. Table holds information such as name and any special notes.
-
 
129
            </td>
-
 
130
         </tr>
-
 
131
         <tr>
-
 
132
            <td valign='top'>
-
 
133
               alias
-
 
134
            </td>
-
 
135
            <td valign='top'>
-
 
136
               things get renamed occasionally. Sites may go by one or two names, clients can change names, and devices especially can change names when pulled and redeployed. However, they are still the same item. This is especially important when automated processes (backups, sysinfo) can update the database and use a different name than is stored her, or when a device has a name change.
134
               Physical sites which may house devices. Table holds name.
137
               <br />while aliases mainly concern devices, the table is set up to also handle site and client, by the field <b>source</b> which holds the name of the table for which this alias refers.
-
 
138
            </td>
135
            </td>
139
         </tr>
136
         </tr>
140
      </table>
137
      </table>
-
 
138
      <p>
-
 
139
         Originally, additional information was to be stored in the device/client/site tables, but they have been removed to decrease the complexity of the base program. Instead, this information will be managed by the modules aliases and notes.
-
 
140
      </p>
141
   </body>
141
   </body>
142
</html>
142
</html>