Is class diagram required to change if DB contains Views on tables? - database

I'm a newbie in designing class diagrams. I follow DAO pattern in my design.
In my project, one user can add multiple contacts which can further be added to many groups.
Let's say 1 contact -> many groups.
As per my requirement UserContact and UserGroup are classes which manage contacts and groups.
In DB contacts and groups are stored in two different tables.
There is one use case to retrieve all contacts along with their groups so that I need to retrieve all contacts first and then using contactID again I need to make a query to get its relative groups.To avoid this in DB, there is VIEW on these two tables.
Now,with VIEW, I need to make one query to get user contacts and groups.
How can I add this method in DAO?
How do I change my classes so that contacts and groups can be mapped to my objects?
The following are the classes involved in this use case.

If I understand the question correctly; you can create a GroupContactDAOImpl class that has only query (get) methods, e.g. getGroupContacts(groupId) or getAllGroupContacts() if you will. Since "group contacts" is not an entity that has its own table, UserContactDAOImpl.addContact and UserGroupDAOImpl.addGroup methods would be sufficient to add new records.
If I need to get groups associated with one contact, how can I map contact information and groups to one object?
If you want to map contact info and groups to one object, you can add a UserGroup property to UserContact class (like in Hibernate). Then GroupContactDAOImpl will have a method like: UserContact getUserContactWithGroups(contactID).
Similarly, if you'd like to get a group's info with all the contacts asscoiated; you can add a UserContact property to UserGroup class. GroupContactDAOImpl will have a method like: UserGroup getUserGroupWithContacts(groupID).
There might be other methods to do the same thing; hope this helps.
As I need to insert and update a contact using UserContact, it should contain only contactID, email and name. I use UserContact and UserGroup as DTOs. Can I create a new class which holds UserContact and UserGroup that uses UserContactDAOImpl and is it a preferable way?
Yes, you can follow that way if you'd like to leave UserContact class as it is. You'd have a new DTO (e.g UserContactWithGroups) and return it from UserContactDAOImpl (e.g .getContactWithGroups method.) You can also create a separate DAO class, but it doesn't matter much. It's best to adapt it to your own use case.

Related

filemaker database relationships

I'm very new to FileMaker currently working on a Mac. I've been assigned a new simple system to work towards completing and I have bumped into some issues with database relationships. I've got experience with PHP/MySQL databases connections etc. but FileMaker seems to require a somewhat different mindset and approach.
I'll try to explain this as simply as I can.
Here's the table relationships in my database
What I'm trying to do is a list of "to-do" notes, an interactive menu where the user can add things that needs to be done. I've done this with a portal on a layout based on the table "site". The portal is based on the table "todo_notes", which is connected to site through the "site_id".
Here's what it looks like in browse mode
What I'm having problems with is adding a relationship between the todo_notes and contacts. The contacts are two separate tables called "county_contacts" and "property_owner_contacts". What I want to accomplish is the possibility for the user to, from a dropdown-list, add a single contact from these two tables. Preferably I'd like to sort of merge these two tables into the same dropdown-list.
Let me know if you need any other information or a better explanation of my issue. Any help is very welcome!
If you have a single contacts table with foreign keys for both county and property owner tables, that would let you have a single list for all contacts. From there you could also build a value list based on a relationship, for example to filter only contacts that belong to either county or property owners.
If you then need to further normalize the tables, fields that pertain to either relationship exclusively could be moved to another table from there, as a one to one relationship, if that is a concern.
The Short Answer
You need to create a Contacts table. Filemaker has no way of dynamically generating value lists. Instead, you can base a value list on any field, therefore, the only way of generating a list of the contact names would be if they were all in the same table.
The Long Answer
Because Filemaker only allows us to use ONE field for a value list, we must create a new table for the contact. I would recommend that you replace the two contact tables with a single contact table,(seeing as the fields look the same between the two tables) and then add a toggle on the contact for Owner or County. However, you could also create a single contact table for all of the fields that overlap that has foreign keys to the owner and county tables.
You would then use the fullname field from the contact and be good to go.
That is, assuming that you did not want to filter the contacts at all or only show contacts associated with this site.
To start with, I highly recommend using the Anchor-buoy method for organizing the relationship graph. Here's an explanation of the anchor-buoy method: http://sixfriedrice.com/wp/six-fried-rice-methodology-part-2-anchor-buoy-and-data-structures/ . It's just a convention, but will help you with the idea of context in FileMaker. It's widely accepted among the FileMaker community as the "right" way to organize a relationship graph. I will continue my explanation using this method.
Each Table Occurrence (the boxes in the graphs, or TO) represents a unique context from which you can view and edit information. In the anchor buoy method, each Table only has one "anchor" TO. I would recommend only using anchor TO's for the context of your layouts. Then, your portal, and any other corresponding information, will be on your buoy TO's. Here is what your new portal relationship would look like. You would select fields from your buoy TO's to use in the portal.
The easiest way to filter your value list by only contacts associated with this site would be to create a foreign key from the contact table to the site, and then add a TO to the graph, for the contact table. You would then click "Include only related values starting from" radio button, and specify your new TO.

How to access entities from many to many relationships

Here is the explanation. I have two entities: House, Person. In my system one person may own multiple houses and one house may have multiple owners. So I create a table (aka entity) called HouseOwnership. I want to be able to make two different kinds of queries against HouseOwnership:
Given a houseId, get all it's owners
Given a personId, get all the houses owned
So for HouseOwnership, I do
#Entity
class HouseOwnership{
#Load
private Ref<House> houseRef;
#Load
private Ref<Person> personRef;
}
How do I make my queries with OfyService.ofy()?
I am tempted to do
owners =OfyService.ofy().load().type(HouseOwnership.class).ancestor(house).list()
and
houses =OfyService.ofy().load().type(HouseOwnership.class).ancestor(person).list()
but for this I would have to make both References into #Parent. So am I allowed to do that? How do I make the queries?
Also I only have the ids not the actual objects so I would have to create the objects from the ids, which I can do. But I am wondering if there is an easier way?
An entity can have only one parent.
You don't need to make your HouseOwnership entity a child of any entity.
You make a simple query to get all HouseOwnership entities where houseRef property equals a given House key, or personRef property equals a given Person key, or both.
You can always make a Key from an ID for entities that have no parents.
You almost certainly want to model this as a #Index Set<Ref<Person>> owners; property on House. Creating an extra relationship entity creates a significant amount of overhead.
Don't try to map schemas literally from relational models - use the document structure to your advantage.

How to do a nested query in SOQL? Salesforce

I have 2 custom objects in Salesforce.com
One is PersonAccount and one is Accounts.
Within the default "Account" object I have a field called user_id
PersonAccount acts as a junction table to link "Account" to Accounts
PersonAccount does a lookup in Person for user_id Lookup(Account)
How can I build a query to check something in Account to find all the matching items in Accounts?
Currently, Salesforce only permits a single level of nested queries. It cane be done like the following:
[SELECT ID, Name, Field1 from Object__c WHERE Id IN ( SELECT Id FROM Object2__c WHERE Field2 = 'SomeValue')]
However, with the junction object you don't actually need to use a nested query.
Unfortunately, your description isn't clear enough to understand your specific object set-up, so I am going to make some assumptions.
You have three objects, Accounts__c (your custom Accounts Objct), PersonAccount__c (your junction object), and Account (the default Account objects).
The PersonAccount__c object contains two lookup fields (for a true Junction, they should be Master-Detail). The first is to Accounts__c (we will call that lup_cust_accounts__c). The second is to Account (we will call that lup_account__c). [As an aside it is a really bad idea to have an Accounts and Account object. It is going to screw you up because Salesforce will automatically pluralize words and then you will be confused as to which is which.]
Salesforce allows dot relationship lookups in SOQL queries. So if you want to get the ID and Name from custom Accounts Objects when the associated Account object's Name is like "Test", you could do the following:
[SELECT lup_cust_accounts__r.Id, lup_cust_accounts__r.Name FROM PersonAccount__c WHERE lup_account__r.Name LIKE 'Test%'];
Notice the double underscore r instead of double underscore c? That is how you indicate a reference (lookup) rather than the specific field value.

Need advice on structure of my database, to create useful Entities

I need people's advice as to whether this the best way to achieve what I want. Apologies in advance if this is a little to subjective.
I want to use Entity Framework V.1 to create something similar to the following C# classes:
abstract class User
{
public int UserId;
public string TelephoneNumber;
}
class Teacher : User
{
public string FavorateNewspaper;
}
class Pupil : User
{
public string FavorateCartoon;
}
I need people's advice as to how to best to persist this information.
I plan to use SQL Server and the normal Membership Provider. It will create for me a table called aspnet_Users. There will be two roles: Teacher and Pupil.
I will add fields to the table aspnet_Users which are common to both roles. Then create tbl_Teachers and tbl_Pupils to hold information specific to one role.
So My database will look a bit like this:
aspnet_Users
int UserId
varchar TelephoneNumber
tbl_Teachers
int UserId
varchar FavorateNewspaper
tbl_Pupils
int UserId
varchar FavorateCartoon
The idea of course being that I can match up the data in aspnet_Users to that in either tbl_Teachers or tbl_Pupils by joining on UserId.
So to summarise, my questions are:
Is my database structure the best option to achieve these classes?
Should I try to wrap the Entities within my own POCO classes?
Should I change my database structure so that EF creates entities which are closer to the classes I want?
EDIT: I re-arranged my question it make it a bit clearer what I'm asking.
If you're using EF 1, then POCO can be a bit unpleasant. Unless there's a good reason not to, I'd just use normal EF entities. Your database model is fine, by the way, and is an example of TPT (Table Per Type) inheritance mapping. You could either use the wizard to create entites from the databaes, or create your entites and map them to the associated tables. If you do the former you'd initially end up with three unrelated entities. You'd then use the designer to tell EF that Pupil and Teacher inherit from User, and that User is abstract.
In general, one of the strengths of EF is that the entities don't have to match that closely to the tables that persist them. In this case though there's a natural mapping.

Table Module vs. Domain Model

I asked about Choosing a method to store user profiles the other day and received an interesting response from David Thomas Garcia suggesting I use the Table Module design pattern. It looks like this is probably the direction I want to take. Everything I've turned up with Google seems to be fairly high level discussion, so if anyone could point me in the direction of some examples or give me a better idea of the nuts and bolts involved that would be awesome.
The best reference is "Patterns of Enterprise Application Architecture" by Martin Fowler:
Here's an excerpt from the section on Table Module:
A Table Module organizes domain
logic with one class per table in the
database, and a single instance of a
class contains the various procedures
that will act on the data. The
primary distinction with Domain
Model is that, if you have many
orders, a Domain Model will have one
order object per order while a Table
Module will have one object to handle
all orders.
Table Module would be particularly useful in the flexible database architecture you have described for your user profile data, basically the Entity-Attribute-Value design.
Typically, if you use Domain Model, each row in the underlying table becomes one object instance. Since you are storing user profile information in multiple rows, then you end up having to create many Domain Model objects, whereas what you really want is one object that encapsulates all the user properties.
Instead, the Table Module makes it easier for you to code logic that applies to multiple rows in the underlying database table. If you create a profile for a given user, you'd specify all those properties, and the Table Module class would have the code to translate that into a series of INSERT statements, one row per property.
$table->setUserProfile( $userid, array('firstname'=>'Kevin', 'lastname'=>'Loney') );
Likewise, querying a given user's profile would use the Table Module to map the multiple rows of the query result set to object members.
$hashArray = $table->getUserProfile( $userid );

Resources