databse v5.
databse v5.
Okay I think I'm beginning to see what you are trying to do.
The VM's are contained within a specific hardware, their specifications would be child records of the actual physical server, however the information about them is basically identical, so simply store them in the same table and identify the type or server.
So I think you would have
tblCustomer - PK - CustomerID Customer details
tblServer - PK - ServerID - containing all the basic information about the the server whether Virtual or Real hardware. It has a field to identify if it is Virtual or Physical. It has a field ParentID which is a ServerID of a physical unit. This is self referencing.
I'm not sure but I think I would store the customer ID here as well.
A server can only belong to one customer?
Can you describe all the attributes that a server can have that you want to store?
Normalisation would dictate that if there are a variable number of attributes they would be stored in a child table, however a server has by definition a processor, memory, storage.
I'm not sure that the number of cores is really needed, as the processor type would tell you that. This is the area I'm grey about, whether to have a child table of attributes or not.
tblApplications - PK - ApplicationID - Contains a list of all Software that can be installed. These would be installed on either a VM or a Server.
Junction Tables
tblServerApps. Indicates which applications are installed into a server, physical or virtual makes no difference.
Fields PK - ServerAppID - AppID - ServerID
A lot of the above is guess work, as I still am not sure of the overall task here, what you are trying to achieve in a plain business sense.
DLookup Syntax and others http://access.mvps.org/access/general/gen0018.htm
Please use the star below the post to say thanks if we have helped !
↓↓ It's down here ↓↓
Hi Minty,
thank you.
I had call with my boss and i found out more![]()
I have to change name t_systems not to application, but to tier.
So we have server and tier - called assume tier1, tier2, tier3.
So customer is choosing server. he can select what he wants to. And for this server is choosing specific tier. So we have tier and specific server for it.
And for each server we are choosing machine - bare metal or virtual machine. For each of them (bm or vm) we can set up additional items - operating systems which can be installed on them (we have few possibilities for each of them). Or not - only if customer wants it. I am not sure if i created proper relationship here (how can i change it?):
Additionally servers can be on production or on test (environment)- depends what customer wants. So for each environment customer decides what servers he wants to use.
Whole relationships are looking right now like here:
I am wondering if i should relationships like here:
Thank you for help !
Best,
Jacek
edit: ignore attachment below:
You are over complicating this.
Every server will be in an environment. Simply make it a field for the server, the same with Physical or Virtual.
You have separated certain server properties into one table but not others / this makes no sense, and in fact probably isn't the way to go.
What is a tier, what does it represent ? I
'm afraid you (or more likely your Boss) keep changing the remit here, you haven't actually sat down and decided what you really need.
Take a deep breath and a large step back.
In plain English (not your native language I know) please describe what the whole business process is.
Not minute details, but as if I was a new employee and you needed to give me an overview.
You currently seem to be trying to create a system without knowing the whole picture.
DLookup Syntax and others http://access.mvps.org/access/general/gen0018.htm
Please use the star below the post to say thanks if we have helped !
↓↓ It's down here ↓↓
You have separated certain server properties into one table but not others / this makes no sense, and in fact probably isn't the way to go. Hi Minty,
thank you. I simple didnt wanted to mess up with this professional words and names.
But i see that we can not go further without it ;-)
like always unfortunately - my whole life is looking like thatYou are over complicating this.Even to become a father i had to "work" a long time (2 years:P).
I see what you mean here but you have server table.Every server will be in an environment. Simply make it a field for the server, the same with Physical or Virtual.
In server table you have:
Server - the name of server
Cpu (i changed name from Model to show exactly what is it) - characteristic Cpu Model Name
CoreSokets - Number of cores provided in the socket
Sockets - number of sockets on server
Numanodes - architecture feature, memory location relative for specific cpu.
Infrastructure - this is a set specific for customer, one will be in cloud, other not
And imagine i will add environment here. Customer1 wants to choose server1 as production environment. Customer2 wants the same server1 but as test.
So in table with servers i would have 2 records for this. So i will have to repeat all data, CPU, CoreSockets,Sockets etc and only change environment?
This will be not redundant?
i hate when you are talking like thatIn plain English (not your native language I know) please describe what the whole business process is.
What we had here - System - this is a topology in our terminology (for example SAP HANA or SAP NetWeaver) - i can call this system btw. Each topology has different characteristics (set of tiers) and it is for different purposes.What is a tier, what does it represent ?
Customers when are choosing for example HANA they know how much memory and space want to allocate.
Once again business model:
I have customers. Customers are choosing set up of tiers - system/topology and for it we have dedicated servers to choose. Each server can be on production or test.
Depending of how we consume servers we have to use bare metal or virtual machine. Using bare metal or virtual machine is connected with later installing operating system on them.
For each server we can have bunch of characteritics as i desribed above. And furthermore we have additionally set of data (like cores = sockets * coresockets of cpu) and memory sizes for each of them.
So for one server they can choose different configurations of memories and cores.
I hope i helped you.
Yes, because this is relationship one to many. Server can have few detailed characteristic with different cores and memories to choose.You have separated certain server properties into one table but not others / this makes no sense, and in fact probably isn't the way to go.
If i have one vig table with Cores, MemSize, CoreSockets, NumaNodes i would have to repeat data.
I would have server1, coresockets2, numanodes2, 20 cores, 32 Gb and etc. in second record the same server but 32 cores, 64 GB, in third record the same server but 64 cores, 256 Gb and so on...
But i am still learning though...
thanks for help Minty,
glad to involve more people in data modelling here, Guys ?![]()
Jacek
This I understand, but not the actual purpose of the database.Once again business model:
I have customers. Customers are choosing set up of tiers - system/topology and for it we have dedicated servers to choose. Each server can be on production or test.
Depending of how we consume servers we have to use bare metal or virtual machine. Using bare metal or virtual machine is connected with later installing operating system on them.
For each server we can have bunch of characteritics as i desribed above. And furthermore we have additionally set of data (like cores = sockets * coresockets of cpu) and memory sizes for each of them.
So for one server they can choose different configurations of memories and cores.
Is it to either
a) Record what the customer has or
b) Provide a platform of possible choices to the customer?
Or some combination of the two. Is this for product / services that you are hosting or selling ?
It isn't clear from the description what the end goal is, but it seems to lean towards b) ?
I'd be happy for anyone else to step in, but without a clear picture of use I'm not sure how much we can help.
DLookup Syntax and others http://access.mvps.org/access/general/gen0018.htm
Please use the star below the post to say thanks if we have helped !
↓↓ It's down here ↓↓
hi Minty,
thank you.
The end goal is to feed up Excel workbook with data from our database. (because Excel is used by customers and they like it).
It is more b) - provide a platform choices to the customer.
But also administrators should have possibility to input new customers and topologies and servers easily.
edit: ask if still is not clear. I think that we stuck at this moment...![]()
Best,
Jacek
Okay so a configuration tool. That makes things a lot clearer.
I'm a little tied up to provide an in depth help for you, but I would be tempted to draw out on paper the basic design, and see if that can achieve your needs.
If you can't do it on paper then you can't do it in Access!
Perhaps you could show us a sample of the expected Excel output for the customer?
DLookup Syntax and others http://access.mvps.org/access/general/gen0018.htm
Please use the star below the post to say thanks if we have helped !
↓↓ It's down here ↓↓
Minty,
thank you very much.
it would be very nice of you.I'm a little tied up to provide an in depth help for you, but I would be tempted to draw out on paper the basic design, and see if that can achieve your needs.
I can't unfortunately. Only what i can write that from this database i want to pull out all queries needed depending on customer and choosen system and server.Perhaps you could show us a sample of the expected Excel output for the customer?
Best,
Jacek
My answer to your diagram is simple, can you put the data you want to retrieve into that layout and sensibly retrieve it to create the document to give to your customer?
Walk it through, using a pen and bits of paper, (or if you like a whiteboard and marker pens)if you struggle to get to the end result, then it will be an even bigger struggle in access.
I'm afraid without seeing the end goal, you are asking a question I can't answer.
I have maintained and updated a complete field service maintenance database, that contained linked equipment types, models with assumed sub parts, power supplies, disk arrays, controllers and a host of other related items. It recorded service calls, engineering activity, parts used, contract billing, calculated stocking requirements based on service levels and multiple remote storage sites. it emailed customers updates on their service calls in real time. It could tell you an engineers activity and if he was on site or travelling, based around a web app linked back to the database, they would update whilst on site.
The equipment relationships weren't as complex a model as you are suggesting.
If you are going to provide a cascading list of what fits into what for servers at a processor/memory level, knowing how quickly the market moves, I think you are possibly making a "rod for your own back".
We had a team of people constantly researching new equipment and its major components, to try and keep up to date, and it was a full time task for 1 - 2 people.
And we only tried to keep on top of it at a higher level. Not down to cores , memory and CPU level of detail.
Not wishing to put you off, honestly.
DLookup Syntax and others http://access.mvps.org/access/general/gen0018.htm
Please use the star below the post to say thanks if we have helped !
↓↓ It's down here ↓↓
Minty,
thank you, you are the best!
I can not share with my Excel unfortunately. But what we walked here - i think i will handle it.
Thanks to you and davegri i know how in which way i should go.
Thank you
Best,
Jacek