i6 Database

Introduction

Each paragraph corresponds to a table (relation) in a relational database. The 'keys' are marked with `*'.

Publications and other information is not included in the model. Also take a look at the two examples (figures) at the end.

(A) Data model

* Id: (consecutive number)
Brand:
Model:
Prize:
Conto: (name or cont_nb then in a special conto_description)
IP number: (string or IP1,IP2,IP3,IP4)
Ethernet nb:
Mhz:
Ram (mbytes):
Disk (mbytes):
Screen Brand:
Screen Model:
Screen size:
Registration (cabinet,screen): (yes,no) (1,0)

* Computer id:
* Computer i/o id: (possible check if already installed)

* Id: (consecutive number)
Type: (scanner etc or special i/o type list)
Bought_year:
Brand:
Model:
Conto:
Specification: (free text)

* Id: (nb)
Name:
Version:
Brand:
Prize:
Conto:
Nb_licenses:

* Id: (nb)
Description:

* Computer id:
* Software id: (no check on number of licenses installed)

* Id: (consecutive number)
First name:
Last name:
Initials:
Position: (professor, associate_professor, …student) (or position_type)
Employment_conto_type: (either project or type with separate type_list)
Group: (either type or name) (design, analyses,....group_c201_1998_99,..)
User_name: (i6xxx)
User_name_alias:
Employed_date_year:
Employed_date_monthday:
Left_date_year:
Left_date_year_monthday:

==== when persons leave (employees or students they are kept in an Archive Person table which can be reached by UNION sql statements.


Person_room:

* Person id:
* Room_nb:

* Room_nb:
(Building):
room_type: (nb)
size:

* Room_type: (1=office, 2=group_room, 3=structrural_lab, 4=material_lab, 5=indoor_lab, ..)
Description:

* Room_nb:
* Room_equipment_type:
Number_items:

* Room_equipment_type:
Name: (kontorsstol, minihub,…)
Description:

* Person_id:
* Telephone_nb:
Telephone_type

* Telephone_type:
Description: 1=room installed, 2=mobile,..)

(B) Create database user access views

• new computer (edb)
• placement of computer and IP number (edb, all)
• software installation/de-installation in computer (edb, all)
• computer i/o installation/de-installation (edb, all)
• software installation (edb)
• telephone_list (secr,all)
• employed (secr, all)
• etc.

(historical personal data can be reached through UNION statements in the SQL statement - special views for these searches)

(C) Plus and minus with a 'clean'/normalized relational database model

+ (pros)
• easy to maintain
• easy to extend
• easy to make new types of extracts
• special user views for different actions
• distributed responsibilities and maintenance
• quite easy to export to other relational databases

- (cons)
• not always overviews direct from single data register
• more initial work in making forms and i/o routines

(D) Next steps

• 'i6db' group set-up. EDB-udvalg plus additional user representatives.
• Requirements formulation including initial user view/functionality definitions according to (B).
• Meeting with i8 Electronic Systems (Wladislav). Possible use of exisiting systems.
• Decision on requirements for i6db system.
• Decision on i6db system development project. Project cost frames. Project participants, needed and available competences.
• It is important to define ambition level and how cost for implementing and long term maintenance shall be distributed over time.
• Prototype runing autumn 1999.
  
  
  

  ---

  See also http://it.civil.auc.dk/it/education/sem6_1999/exercises/db_normalise.html where the semester 6 exercise on relational databases shows how an Access implementation of a student-group-project can be made.
  
  

  ---

  
  
  See also http://delphi.kstr.lth.se/reports/swebu97/swebu97.html#Heading18

  ---

  [projects]

  Per Christiansson