Page 2 of 3 FirstFirst 123 LastLast
Results 16 to 30 of 36
  1. #16
    orange's Avatar
    orange is offline Moderator
    Windows XP Access 2003
    Join Date
    Sep 2009
    Location
    Ottawa, Ontario, Canada; West Palm Beach FL
    Posts
    16,870

    The database is not trivial. The real issue is that the facts may not yet be all defined. You know the business situation better than anyone. You have to get it mapped out to facts and into a normalized structure. (But you don't know Access nor database, so it will seem complex and confusing---one step at a time and you'll get there.)

    I do not understand why you have a one to one relationship between customers and POC as well as customers and buildings.
    Not really - you have a finite set of Customers - every Customer can be looked at as a POC for a Room or a Facility Manager for a Building. That's what the relationships between Customer, Facility Manager and POC are trying to show (super type Customer with complete subtypes FacilityMgr or POC).
    Based on your statement
    The only difference between a room POC and a facility manager is the facility manager is the POC for the entire building, whereas a room POC is the point of contact for a room.
    I chose to separate Facility Manager (Bldg poc) and POC as Room poc, because you seemed to identify both Facility Manager and POCs. As I said, if this structure doesn't meet/support your business facts, then adjust it accordingly. The database must support all of your business facts.

    Similarly, Switches (my best guess based on your comment that Switches could be in Rooms or in cabinets in Rooms -which may be hiding some facts). To account for all Switches, I broke Switchs into RoomSwitches and CabinetSwitches, since the total of RoomSwitches +CabinetSwitches has to equal all Switches. There may be several ways to set it up, but that's what I did.

    You are correct that forms should be focused to business entities. For example, you could add Buildings, and Customers, and Switches. Then you could identify Rooms within Buildings. You could have a form to assign Facility Managers to Buildings. You could start with a blank form, then have a combobox of Buildings and a combobox of Facility Managers. You'd select a Building, then a Facility Manager, then create a Facility Manager record for Building X. Similar set up for assigning POC to Rooms. You know the business, so it isn't trying to do all tables at once--it is designing a form(interface) from which you can select the pieces you want to relate and create records(store data in the database). I understand it seems overwhelming -- you're new to Access and do not have experience with database concepts. Seems to me you're doing quite well- you have done some tutorials, you recognize there are things you don't follow/understand and you are raising questions --AND you are looking for additional learning materials. Read through a lot of threads --people with 200+ posts are still trying to bypass/ignore normalization (go figure?).

    As I tried to point out early in the thread, getting all the facts described and getting your tables and relationships designed to meet your business needs is critical. It takes time and it takes experience. Some of us have been at this for many, many years. You are new, as you have said, and your project isn't fully defined (in my view) and database is not the same as just buying the Access software (as many marketers would have you believe).

    There are youtube videos by 599CD that lead you through the Access basics.
    Also, an excellent set of videos by Steve Bishop.

    Also check out this "stump the model approach".

    This post has some info that could be useful to you. (some database concepts)

    Good luck.

  2. #17
    ittechguy is offline Competent Performer
    Windows 8 Access 2013
    Join Date
    Aug 2015
    Posts
    218
    Thanks for all the help. I don't know where I'd be without you.

    It seems to me like my relationships fit my requirements. Perhaps I should break both my customers table apart further as well as my switches table for the sake of normalization. Rank, organization, shop name, office symbol, switch model, type, software version... all that would contain redundant data and might be better as a combo box.

    One thing I don't understand about combo boxes is I'm not sure how to link it to the main form. I know I can build a combo box on a separate query. But my subform is linked to my main form by the customer ID. It's the only way I know to relate the main form to the subform.

    I'd need different comboboxes for different tables. Buildings, rooms, security method, etc. I could have an unbound form and create combo boxes manually each based on their own query, but I do not know how to relate it to the customer ID from the main form.

  3. #18
    orange's Avatar
    orange is offline Moderator
    Windows XP Access 2003
    Join Date
    Sep 2009
    Location
    Ottawa, Ontario, Canada; West Palm Beach FL
    Posts
    16,870
    Did you look at the database I included in the zip file?

    As for combos etc, don't do that yet.

    It seems to me like my relationships fit my requirements.
    Get some sample data (even pencil and paper) and some test scenarios, make sure you can "run" your test scenario and get the proper data output. If the model doesn't handle all your scenarios, you have to find out why, then adjust whatever.

    Look at the links I gave when you want to learn more Access --the youtubes are quite good.

  4. #19
    ittechguy is offline Competent Performer
    Windows 8 Access 2013
    Join Date
    Aug 2015
    Posts
    218
    I figured it out. You've been a big help. It took a lot of trial and error.

    I replaced the one to one relationship you had between customer and POC (also customer and facilitymgr) because it wasn't allowing one customer to be the POC for many buildings/rooms.

    I couldn't figure out how to get my query right with the large number of tables you had in your database. I also couldn't figure out how to get consistent data using several different tables which contained both the building ID and room ID. So I cut out some tables and what I have here works. Click image for larger version. 

Name:	Untitled.jpg 
Views:	13 
Size:	109.8 KB 
ID:	21949

  5. #20
    orange's Avatar
    orange is offline Moderator
    Windows XP Access 2003
    Join Date
    Sep 2009
    Location
    Ottawa, Ontario, Canada; West Palm Beach FL
    Posts
    16,870
    Good stuff. Work with pencil and paper- identify some outputs that the database must be able to provide. Make sure you can get that data from the tables and relationships.
    It was my understanding that Customers were either Facility Managers or POC, where FacilityMgr was POCcontact for entire building and POC was contact for Room. But your adjustment seems to be a refinement of business rules/facts and, as I said before, adjust as necessary to meet your requirements.

    A few things I see that I don't understand in your diagram
    -in tblRooms what is the difference between RoomsID and RoomID
    -since Bldg determines Room, I don't see the need for tbl RoomName. RoomName could be an attribute(field) in Rooms.
    -in Building you really should have a Identifier field and a BldgName. This may help you with relationships and prevent misspellings of BldgName. It could allow for BldgName change by changing only 1 occurrence of bldgName. The linkages would be on BldgId
    -Security options relate to Rooms not RoomNames. I think RoomName is masking an entity or attributes that have not been clearly defined. As mentioned previously, you should write a 2-3 line description of every entity (and field) for documentation and to clarify the terms for you and others.
    -tblSwitches was intended to be about Switches not where Switches are located. That's the purpose of RoomsToSwitches (junction) where the RoomID and SwitchID would be unique. Again, I would not use RoomNameID.
    -If there is something explicitly different between tables Rooms and RoomName then you should research it so it is absolutely clear.

    Note: This is all part of business analysis to get all the facts in order to design a database to support the business. It is key to get the tables and relationships designed before getting too deep into Access.

    Good luck with your project.

  6. #21
    ittechguy is offline Competent Performer
    Windows 8 Access 2013
    Join Date
    Aug 2015
    Posts
    218
    You are right, a customer is either a building manager, POC for room, or both. I'm going to rename my customers to rooms table to POC.

    As for my rooms/room name table, I thought that room name should be in one table. However now that you mention it and I think about it, I'm going to remove room name and add fields to my rooms table.

    The room id field in switches needs to be removed, I forgot to do that.

  7. #22
    orange's Avatar
    orange is offline Moderator
    Windows XP Access 2003
    Join Date
    Sep 2009
    Location
    Ottawa, Ontario, Canada; West Palm Beach FL
    Posts
    16,870
    ?? Nothing about Room should be in the Switches table.

    Room and Switch come together in RoomsToSwitches. This might be better understood with a name like
    RoomContainsSwitch ( at least that is how I interpret the table).

    The database I provided previously was generated from the data model. That is why I keep saying you have to get your tables and relationships designed before you build your database. You can use the database as a starting point and adjust as necessary. But all adjustments will be based on business facts and details, not guesses.

    Have you got descriptions for all tables and fields? It is a worthwhile exercise.

    a customer is either a building manager, POC for room, or both.
    I was not aware of the or both. In my set up they were one or the other. This is the sort of detail that comes out during analysis.

    Instead of working with a bunch of forms at this point in time, I recommend you make a list of things you want to get from the database. I see you have some test records. Now make a list of the proposed outputs and use queries to answer each of these required outputs. If you can't get the output, then something isn't correct. Could be the data; could be the tables; could be a relationship??? You have to sort out what is causing the issue and resolve it; then repeat the testing until all required outputs can be "extracted from the database". Then, it is time to develop the interface.
    Good luck.

  8. #23
    ittechguy is offline Competent Performer
    Windows 8 Access 2013
    Join Date
    Aug 2015
    Posts
    218
    You're right, nothing from rooms should be in switches. As I said, I was going to delete that. Also, I get what you're saying about not working with forms until the database relationships are solid.

    I put together a nice long essay detailing the database requirements. Its really helped me out a lot. If you care to read all 2 pages, I've attached it here.

    In light of what you've said here, and what I've discovered from writing out my database requirements, I will add the buildingID back to the buildings table. Also, I figured it is best to plan ahead when designing this database. That is, currently I only have a need to store switches. However, in the future I would like to store several different types of equipment. Each all linked to a specific room. I am not sure how to do this. I first tried creating an equipment table and having a FK for switches, a FK for routers, etc in that table and having roomsID link to the PK for my equipment table. But I scrapped that because it would make it difficult if some rooms only had switches but no routers, or if I needed to remove a switch or router from a room.

    I'm thinking instead of a single equipment table I'll have a separate table for each type of equipment (switches, routers, etc) and each will be linked to the roomsID. That might work. Database Objective.zip

  9. #24
    orange's Avatar
    orange is offline Moderator
    Windows XP Access 2003
    Join Date
    Sep 2009
    Location
    Ottawa, Ontario, Canada; West Palm Beach FL
    Posts
    16,870
    It's good to write things down - definitions of all the pieces. It helps to clarify. It is absolutely essential if you have to come back in a year or two and make some adjustments/additional features. It is very difficult to take over a system that has no documentation, no standards and no one who'll admit having participated in its development.

    You should build the general case/holistic model - enterprise/conceptual level. Then focus on the areas of the model of most interest to you/your current project. Expand on the level of detail for your project, always ensuring it fits the bigger picture. Much of the big picture may only be "artist's concept" level of detail. You know like the first picture you see of a proposed new shopping mall. The architects are focused on the sewers, electrical, utility stuff but they're showing a picture of buildings, parking lot.....
    The example you have with Equipment is a good example. Here's a model that deals with IT Assets --which can include routers, NICs, cables...whatever you want. You can add an AssetType too, if necessary to limit what's being managed. The big question is how practical would it be to record all of these things? How would it be kept up to date? Identify what scope is practical with the resources available and make sure management understands/agrees.

    Aside: I remember when we had a first LAN; then multiple vendors of servers and PCs; then multiple LANs on various floors or various buildings.... It just kept growing. So no database on some PC on someone's desk was going to be a practical solution that was easily maintained and "accurate". The big physical chunks were managed via a Materials Asset management system --- PC belong to directorate X sort of level. But as networks became more common and management more centralized, there was an application that could do an inventory of each PC (networkID) by assigned username via the network automatically. This could do everything from software titles, versions, serial numbers; same with NIC and hard drives... The big picture inventory became more realistic, even though it couldn't be populated in the beginning.

    Can you post a copy of the database with your test data? I'll take a look, and may be able to help with some things if I have a copy of what you're looking at and a specific question in context. It's very difficult to offer focused comments/suggestions/help when we're talking about different things and not sure what others mean/meant by such and such.

  10. #25
    ittechguy is offline Competent Performer
    Windows 8 Access 2013
    Join Date
    Aug 2015
    Posts
    218
    If access had a way of automatically making a network diagram type of report... that is, it showed the many switches/routers/servers we have and listed them by switch name and IP address and showed the ports that they were connected to, then recording cables/port information would be extremely practical.

    At this point, one of our network engineers updates our network connectivity diagram whenever changes are made. If access could generate the report that'd save him time. But it wouldn't be practical to build such a database as it would take an unbelievably large amount of time to enter the data. Perhaps if access could connect to the server that manages our switches, I'd feel differently about this. But I for sure can't make that happen.

    I've attached a copy of my database. I still haven't figured out how I'm going to setup the rooms/equipment/switches relationship. Also there's a lot of tables,queries, and forms that I need to delete. Sorry for the confusion. BuildingsSwitches3 (2).zip

  11. #26
    orange's Avatar
    orange is offline Moderator
    Windows XP Access 2003
    Join Date
    Sep 2009
    Location
    Ottawa, Ontario, Canada; West Palm Beach FL
    Posts
    16,870
    Just looked at your database. It asks me for building parameter before I see anything?
    Not sure why CabinetID is in Room table -- can a Room have no cabinet, or some with >1 cabinet?

  12. #27
    June7's Avatar
    June7 is offline VIP
    Windows 7 64bit Access 2010 32bit
    Join Date
    May 2011
    Location
    The Great Land
    Posts
    53,771
    How to attach file: http://www.accessforums.net/showthread.php?t=70301 To provide db: copy, remove confidential data, run compact & repair, zip w/Windows Compression.

  13. #28
    orange's Avatar
    orange is offline Moderator
    Windows XP Access 2003
    Join Date
    Sep 2009
    Location
    Ottawa, Ontario, Canada; West Palm Beach FL
    Posts
    16,870
    @June7,
    Yes I'm aware. Have been responding to posts from start. OP is learning and asking, and is jumping ahead a little.
    He is still doing some analysis to identify, research and define some facts that are causing confusion.

  14. #29
    ittechguy is offline Competent Performer
    Windows 8 Access 2013
    Join Date
    Aug 2015
    Posts
    218
    Quote Originally Posted by orange View Post
    Just looked at your database. It asks me for building parameter before I see anything?
    Not sure why CabinetID is in Room table -- can a Room have no cabinet, or some with >1 cabinet?
    That's part of the junk I have to delete. When I added my buildingid back it messed up my subform and some queries. I'll get around to fixing all that today and send you a copy.

    Yes, a room can have no cabinet. A few have more than 1.

  15. #30
    orange's Avatar
    orange is offline Moderator
    Windows XP Access 2003
    Join Date
    Sep 2009
    Location
    Ottawa, Ontario, Canada; West Palm Beach FL
    Posts
    16,870
    Yes, a room can have no cabinet. A few have more than 1.
    Which means CabinetID doesn't belong in Room table. You need a 1 to Many eg RoomContainsCabinet

    You really don't need forms at the moment. You probably did that to populate tables. For a few test records, I'd stick them in via the table--but that's only for a few test records in each table. In fact, you can map out your test record on paper an enter them into the tables.

    I went back to the original database I sent in zip and added some test records. Here are a couple of queries to get info. This is pretty basic, but is intended as proof of concept. I may have misunderstood various facts, so nothiing here is carved in stone.

    Customer
    CustomerID Organization ShopName OfficeSymbol Rank LastName FirstName PhoneNo Email
    1 ABC alpha @##$# Doe John
    2 ABC beta $$@ Payne Hezza
    3 XYZ charlie (() Bear Kodiack

    Building
    BuildingID BuildingName
    1 EAST TOWER
    2 PhysScience
    3 HeavyEquip 100
    4 FireStation6

    FacilityMgr
    CustomerID BuildingID
    1 2
    2 1

    POC
    CustomerID BuildingID RoomID
    3 4 3

    Query - WhoAreFacilityManagers
    LastName FirstName BuildingName RoomName
    Doe John PhysScience TrainingRm1
    Doe John PhysScience TrainingRm2
    Doe John PhysScience TrainingRm3
    Doe John PhysScience Exec Complex
    Payne Hezza EAST TOWER BoardRoom
    Payne Hezza EAST TOWER LunchArea

    Query --POCForSpecificRoom
    SELECT Customer.LastName, Customer.FirstName, Building.BuildingName, Room.RoomName
    FROM (Building INNER JOIN Room ON Building.BuildingID = Room.BuildingID) INNER JOIN (Customer INNER JOIN POC ON Customer.CustomerID = POC.CustomerID) ON (Room.BuildingID = POC.BuildingID) AND (Room.RoomID = POC.RoomID);

    Query --ShowAllPOCByBldgAndRoom
    Code:
    SELECT Customer.LastName
        ,Customer.FirstName
        ,Building.BuildingName
        ,Room.RoomName
        ,"SpecificRoomPOC" AS ROLE
    FROM (
        Building INNER JOIN Room ON Building.BuildingID = Room.BuildingID
        )
    INNER JOIN (
        Customer INNER JOIN POC ON Customer.CustomerID = POC.CustomerID
        ) ON (Room.RoomID = POC.RoomID)
        AND (Room.BuildingID = POC.BuildingID)
    
    UNION
    
    SELECT Customer.LastName
        ,Customer.FirstName
        ,Building.BuildingName
        ,Room.RoomName
        ,"BldgPOC" AS ROLE
    FROM (
        Building INNER JOIN Room ON Building.BuildingID = Room.BuildingID
        )
    INNER JOIN (
        Customer INNER JOIN FacilityMgr ON Customer.CustomerID = FacilityMgr.CustomerID
        ) ON Building.BuildingID = FacilityMgr.BuildingID;
    Which gives output
    Code:
    LastName    FirstName                          BuildingName    RoomName       role
    Bear                  Kodiack               FireStation6          LunchRoom    SpecificRoomPOC
    Doe                   John                  PhysScience           Exec Complex    BldgPOC
    Doe                   John                  PhysScience           TrainingRm1    BldgPOC
    Doe                   John                  PhysScience           TrainingRm2    BldgPOC
    Doe                   John                  PhysScience           TrainingRm3    BldgPOC
    Payne                 Hezza                 EAST TOWER            BoardRoom    BldgPOC
    Payne                 Hezza                 EAST TOWER            LunchArea    BldgPOC

Page 2 of 3 FirstFirst 123 LastLast
Please reply to this thread with any new information or opinions.

Similar Threads

  1. problems creating one to one relationship
    By alexthefourth in forum Access
    Replies: 5
    Last Post: 11-11-2013, 06:16 PM
  2. Relationship problems
    By BarbT in forum Access
    Replies: 5
    Last Post: 09-05-2011, 09:39 AM
  3. Relationship problems!
    By oo0tommyk0oo in forum Access
    Replies: 11
    Last Post: 07-18-2011, 11:47 AM
  4. Relationship problems in access
    By danish raza in forum Database Design
    Replies: 1
    Last Post: 07-10-2011, 05:50 AM
  5. Relationship problems????
    By geoffishere in forum Access
    Replies: 6
    Last Post: 02-07-2010, 04:01 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Other Forums: Microsoft Office Forums