I am having the following case:
There is entity 'Master_Entity'. This entity has properties as name, type, duration etc. There are other two type of entities 'Entity' and 'Sub-Entity'. There are identical as the 'Master_Entity' (They have absolutely the same properties).
At the end the 'Master_Entity' should hold a collection of 'Entity' and 'Entity' should hold a collection of 'Sub-Entity'. The tricky part is that records of type 'Entity' can be part of different 'Master_Entity' (same for 'Sub-Entity'), but they can have different values for duration for example. How can achieve such modularity?
Here I came up with, but it's not quite do the work. May you guys help me with this.
Edit: Imagine this as some sort of a work tracker. For example you have a 'Create PHP App' (Master entity). This entity contains duration of how long it will take to finish this job. In addition it contains a entity 'Writing Code' (Entity) and this one can be divided to 'Writing Http Client' (Sub-Entity) which has duration property which is specific for this job.
On other side you might have other job: 'Create an Java App' (Master Entity) which will contain the same 'Writing Code' entity, but with duration which will have different value, because of the context of the Application you are building.
I want to have a single record 'Writing Code', but the duration value that it have should be different for every job it's assigned to. How can achieve that with creating a minimum duplicating records of type 'Entity'?
It sounds like something like these 3 tables will work for you:
Entity
* Id
* Name
* Type
EntityGroup
* Id
* Name
* ParentEntityGroupId
* ParentEntityId
EntityRelationship
* Id
* EntityId
* ParentEntityId
* EntityGroupId
With this structure, you can have an Entity be a member of a Group, or a solo Child of another Entity. You can also have a Group be a Child of an Entity, or even a Child of another Group. Without knowing specifics of your data, it's hard to know what you might need, but this should get you started.
From what you have said, it seems that you don't need EAV at all because you don't have different properties for each item just different values. And thus you should not be using it.
What you need is a combination of lookup tables and then tables that address the actual tracking history of the work. This is because this is time sensitive data. The tasks at the time the projects was created may be substantially different than the tasks associated with that task group two years from now, but you need to record the tasks at the the time of creation). Note that this is not denormalizing, it is creating a picture of data in time. The real duration always goes to teh project not ever to the Task. In the task, you can have a suggested duration to use as a starting point. I used a similar design (with far more fields of course) to design a database for building sales proposals for technical-hardware related projects. The real key here is to recognize what data needs to be stored as a point time time and what is lookup data used to build the final project data. If someone adds a new task to the "Create a Java App" group, you don't want to change details about projects already completed or in work, only new projects.
So you need:
Task group
Task Group ID
Task Group Name
Task
TaskID
Task Name
SuggestedDuration (can be null if you have tasks that are always different
but filled in for tasks that usually have a similar duration)
Task_Taskgroup
TaskID
TaskGroupID
Project
ProjectID
ProjectName
TaskGroupID
ProjectTask (should be filled in automatically when the task group is
chosen for the project)
ProjectID
Task ID
EstimatedDuration (fills in the default value, but can be changed
by the person creating the work project)
ActualDuration (Field in after the task is done, can be used by an
analyst to create more reflective task default duration values)
Of course each of these tables may have other fields depending on the need.
Related
I'm quite new to MS Access, but I'm trying to set up a database for building management and regulation in MS Access, which is going to be used for energy use modelling of the building. I therefore have multiple tables which i control with forms. There are multiple zones in a building with different occupations, e.g. one zone is offices, the other a recreational area. In those zones are multiple rooms which have the same occupation. I have a form which provides an overview of the zone, with data such as area size, floor nr etc., but also with a list of rooms that are in that zone. The zones with respective occupation and other data are in one table, the list of rooms is a different table.
What I want it to do, is that when I change the occupation of a zone in the overview form, all the rooms in that zone also change to that occupation.
Info:
Zones table contains fields 'Zone_code', 'Occupation' and non related zone specific data
Rooms table contains fields 'Room_ID', 'In_zone', 'Occupation', and room specific data
I've tried using macro's on the 'Onchange' event, where I would select the table, select the data where the zone are equal, and than set the value to the changed occupation. I've also tried it with selecting the subform of the roomlist. I've also tried using an update query, but I encountered errors updating using a variable.
I had to do the same for the floors, where there are multiple zones per floor and have a table for that overview. I'll show the macro that worked there, but when I used a similar one for the rooms, I got errors such as 'The object doesn't contain the Automation object "Roomlist"'. I even tried update queries but I feel lost.
The macro that worked for the floors where 'main' is the main building table with the floors:
https://imgur.com/a/3rED1Pw
The macro i used for the rooms:
https://imgur.com/gvMDIzq
I used the iif statement to compare zones and only update if the zones are the same but this macro crashes, other macro's i made only added 1 new room with the new occupation, but nothing else.
I expected the macro to just run down the table of the rooms and change the value of the ones where the zone code is the same. Or at least, that is what i hope the database will do eventually.
Can somebody help me figure this out so that it works? I feel I'm missing or overlooking one small thing but I don't understand access enough yet to figure out what. I don't mind if the solution uses a completely different aspect of access, as long as it works. Thanks in advance
Let me start out by saying welcome to the site and MS Access! To answer your question, I would start by looking at your data setup. As mentioned by June7, having Occupation in both tables independently is not necessary. Think of it this way: if I have a value I want to update (such as in this case with your question), it is much easier to update in one location than in multiple locations. From what you've shared, [Occupation] only applies to the [Zone_Code] table and should be present only in that table. Through the relationship of [Zone_code] to [Room_ID] through the [In_Zone] field, [Occupation] of the zone that the room is part of can now be queried.
Another thing to consider is having a table, say 'tbl_Occupation' or something of the like, where you could have the fields [OccupationID] and [Occupation]. Doing this could make it easier to maintain the occupations for which a zone can be assigned (if the reference name of an occupation changes but it is not a different occupation, etc.), and also stores occupation in one location, so that if an occupation is assigned to multiple zones, the ID is referenced instead.
I hope this helps!
(access key for SAP standard modifications needed for test data of this question)
Introduction:
I want to find a certain type of modification to a certain SAP standard repository object (IDES test dataset).
The modification is located in the include of a function group (it is listed under System-defined Include-files in the functionpool of the function group).
So far, I found the table SMODILOG as a central list of modifications (Log of Customer Modifications to Dev. Env. Objects).
Test Data:
My test data is function group V07A, that has e.g. the include LV07A014 (Part of the LV07ANNN include). This was modified by inserting stuff in its source code (one needs an access key in order to be allowed to do this) such as:
*{ INSERT IDSEXAMPLE 1
* this is a comment, which was added
*} INSERT
Goal:
Subsequently I want to find a table where all modifications like this are listed. I want to find the place of modification, i.e. the object type and program id of the object that was modified.
2 Questions:
I realize that the SAP standard include of a function group has a different object type and program ID than the top-include and uxx-includes.
Whereas the latter are of type PROG and prgmid R3TR (found in object catalog entry), the LV07A014 has an object catalog entry identical to the function group that it belongs to, namely R3TR FUGR. This is already peculiar to me. This seems to me as if the resolution to the sub-level (include level) is missing.
In addition, the modification to LV07A014 is listed in table SMODILOG as having the object type (field sub_type) REPS (the pgmid is not included in SMODILOG). I would expect PROG, as for the other inclueds (LTOP, LUXX).
-> Why is there a difference of object types, programids between L_TOP, L_UXX on the one hand and L_NNN Inclues on the other? (Or am I mistaken?)
-> Where can I find information of all SAP standard modifications in my system and the true object type,pgmid belonging to these modified objects (and not the function group that the modified object belongs to, this resolution does not suffice)?
There is no table or something similar where all modifications are listed. The table E071 is a good source to check pgmid and object type.
Why there is a difference of object types, program IDs between L_TOP, L_UXX on the one hand and L_NNN Includes on the other remains a mystery. SAP...
Why do you need a table? For what? Is it purely academic question or connected with real life tasks?
Have you ever tried SE95 transaction? It lists all modifications that were done in system disregard of object type and name. Yes, and function groups too. They are easily searchable by hierarchy
If it is FUGR include that was modified, then it will be listed in the node Outside of modularization units
Finally RTFM, bro...
I need to scheduled events, tasks, appointments, etc. in my DB. Some of them will be one time appointments, and some will be reoccurring "To-Dos" which must be checked off. After looking a google's calendar layout and others, plus doing a lot of reading here is what I have so far.
Calendar table (Could be called schedule table I guess): Basic_Event Title, start/end, reoccurs info.
Calendar occurrence table: ties to schedule table, occurrence specific text, next occurrence date / time????
Looked here at how SQL Server does its jobs: http://technet.microsoft.com/en-us/library/ms178644.aspx
but this is slightly different.
Why two tables: I need to track status of each instance of the reoccurring task. Otherwise this would be much simpler...
so... on to the questions:
1) Does this seem like the proper way to go about it? Is there a better way to handle the multiple occurrence issue?
2) How often / how should I trigger creation of the occurrences? I really don't want to create a bunch of occurrences... BUT... What if the user wants to view next year's calendar...
Makes sense to have your schedule definition for a task in one table and then a separate table to record each instance of that separately - that's the approach I've taken in the past.
And with regards to creating the occurrences, there's probably no need to create them all up front. Especially when you consider tasks that repeat indefinitely! Again, the approach I've used in the past is to only create the next occurrence. When that instance is actioned, the next instance is then calculated and created.
This leaves the issue of viewing future occurrences. For this, you can start of with the initial/next scheduled occurrence and just calculate the future occurrences on-the-fly at display time.
While this isn't an exact answer to your question I've solved this problem before in SQL Server (though database here is irrelevant) by modeling a solution based on Unix's cron.
Instead of string parsing we used integer columns in a table to store the various time units.
We had events which could be scheduled; they could either point to a one-time schedule table that represented a distinct point in time (a date/time) or to the recurring schedule table which is modelled after cron.
Additionally remember to model your solution correctly. An event has a duration but the duration is unrelated to the schedule (but an event's duration may impact the schedule by causing conflicts). Do not try to model duration as part of your schedule.
In the past when we've done this, we had 2 tables:
1) Schedules -> Includes recurrence information
2) Exceptions -> Edit/changes to specific instances
Using SQL, it's possible to get the list of "Schedules" that have at least one instance in a given date range. Then you can expand in the GUI where each instance lies.
I'm currently logging all actions of users and want to display their actions for the people following them to see - kind of like Facebook does it for friends.
I'm logging all these actions in a table with the following structure:
id - PK
userid - id of the user whose action gets logged
actiondate - when the action happened
actiontypeid - id of the type of action (actiontypes stored in a different table - i.e. following other users, writing on people's profiles, creating new content, commenting on existing content, etc.)
objectid - id of the object they just created (i.e. comment id)
onobjectid - id of the object they did the action to (i.e. id of the content that they commented on)
Now the problem is there are several types of actions that get logged (actiontypeid).
What would be the best way of retrieving the data to display to the user?
The easiest way out would be gabbing the people the user follows dataset and then just go from there and grab all other info from the other tables (i.e. the names of the users the people you're following just started following, names of the user profiles they wrote on, etc.). This however would create a a huge amount of small queries and trips to the database in a while loop. Not a good idea.
I could use joins to retrieve everything in one massive data set, but how would I know where to grab the data from in just one query? - there's different types of actions that require me to look into several different tables to retrieve data, based on the actiontypeid...
i.e. To get User X is now following User Y I'd have to get my data (User Y's username) from the followers table, whereas User X commented on content Y would need me to look in the content table to get the content's title and URL.
Any tips are welcome, thanks!
Consider creating several views for different actiontypeids. Union them to have one full history.
I need to implement a feature similar to the one provided by Microsoft Outlook to make your meeting appointment recurrent. I am trying to figure out the optimized Database design that I will be requiring for implementing this feature.
The requirement is something like that each run or task entered by the user will also be applicable for scheduling like a recurrent event - weekly, monthly or yearly. Could you please suggest me the Database model - table structure (with constraints) for storing these details in the DB which can be afterwards accessed by the program to do the appropriate task. Screenshots for some of the possible scheduler details can be found at the following link.
We have a mysql DB running at the backend for storing these details. As soon as the user submits a request, a request id with the details of the request is stored in the table and then a action corresponding to it is taken by the program. More clarification would be like that the users intent is to run a sql script,getting the values and then performing statistical analysis to it. But as the oracle reference DB is dynamically updated by many users, he wants to run it in a recurrent manner and get the analysis done. Note that the mysql db and the ref DB are different.
Please let me know if you require any other details.!
I would suggest storing the details of the first occurence in one table (scheduled tasks) and then the recurance (recurring tasks) details in another.
I might also then be tempted to update the scheduled task table with the next occurance as each task is completed.
As for the Table layout, a rough sketch would be as follows:
[ScehduledTasks]
TaskId (Primary Key)
Description and Details etc...
Start Datetime
End Datetime
[RecurringTasks]
TaskId (Foreign Key)
Frequency : Daily, Weekly, Monthly or Yearly.
DayNo : What Day to run on (1-7 for weekly, 1-31 for monthly, 1-365 for yearly)
Interval : Every x weeks, months etc.
WeekOfMonth : first, second, third... etc If populated then DayNo specifies the day of the week.
MonthOfYear : 1-12.
EndDatetime : The last date to perform
Occurences : The number of times to perform. If this and the previous value are null then perform for ever.
Obvious certain fields would be blank depending on how the task was set up, but I think the above covers all you would need to emulate the tasks in Outlook.