Jim,
There are at least two valid approaches to physical database design. 
The top-down (outside-in) approach and the bottom-up (inside-out)
approach.  I personally always use the bottom-up approach. 
Temporarily ignoring my reporting requirements, I document the
Entities (people, project, departments, companies, etc.) that my
system is about. I document each entity's attributes.  Then I document
the relationships between the entities.  I create a table for each
entity and a table-column for each attribute.  This part of my
solution is used for add/change/delete processing. The relational
database theory tell me if I don't do this I will experience update
anomalies (or at least difficulties).
Then I study my reporting requirements noting which table-columns are
required for each report.  Then in M.S. Access I create a query for
each report that brings together the required data.  I use the M.S.
Access report writing facility.  The report writing becomes very easy.
 I just point each report at a single query.
Dick

--- In [email protected], "comsol0418" <[EMAIL PROTECTED]> wrote:
>
> 
> Jim
> 
> We design tables to produce reports, agree, cool, So always consider 
> what the report should look like before you attempt to design a 
> table. this will guide what fields need to be created to achieve the 
> desired layout. 
> 
> Can you imagine the dificulty to produce a single report from all 
> those tables you proposed :)
> 
> Anyway, You don't need so many tables, the tables you'll need are:-
> 
> - tblBuilding (with all the field you have)
> - tblDepartments
>      -DeptID
>      -DeptNAME
>      -etc
> - tblInventory
>    
> include all the fields you have for all the other tables in this 
> table, add another field call "TYPE" ie type of equipment, eg. Tower, 
> Software, printer...
> 
> then, base on the 'TYPE' enable the related fields.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --- In [email protected], "luvmymelody" <luvmymelody@> 
> wrote:
> >
> > Hello all,
> >  
> > I am developing a database for computer inventory regarding several 
> > departments in different buildings. There are 3 buildings and 10 
> > departments. There are several departments in one building and each 
> > department has a computer. I have always struggled with the 
> physical 
> > model of designing a database. Can someone take a look at the table 
> > structure and let me know if I am on the right track? I will 
> > probably need to break out the peripherals to different tables also?
> > Thanks
> > Jim Wagner
> >  
> > Building 
> > BuildingID 
> > BuildingName 
> > Address 
> > City 
> > State 
> > Zip 
> > 
> >  
> > Unit 
> > UnitID 
> > UnitName 
> > UnitNumber 
> > UnitPhone 
> > BuildingID 
> > 
> >  
> > Monitor 
> > MonitorID 
> > Manufacturer 
> > ModelNumber 
> > SerialNumber 
> > BuildingID 
> > 
> >  
> > Tower 
> > PCID 
> > Manufacturer 
> > ModelNumber 
> > SerialNumber 
> > CPUSpeed 
> > CPUName 
> > RAM 
> > HardDiskSize 
> > Description 
> > BuildingID 
> > 
> >  
> > Periphials 
> > Mouse 
> > Keyboard 
> > Printer 
> > Fax 
> > BuildingID 
> > 
> >  
> > Printer 
> > PrinterID 
> > Manufacturer 
> > ModelNumber 
> > SerialNumber 
> > BuildingID 
> > 
> >  
> > ProductKey 
> > ProductKeyID 
> > ProductKey 
> > BuildingID 
> > 
> >  
> > Registered Number 
> > RegisteredID 
> > RegistereNumber 
> > BuildingID 
> > 
> >  
> > Software 
> > SoftwareID 
> > Title 
> > SoftwareDescription 
> > Manufacturer 
> > BuildingID
> >
>


Reply via email to