How to model something if the desired information is the same as an already existing record e.g. Address (Street, Country, Province, Zip)
We need to capture an User who has a permanent address and an address for correspondence (i.e. 2 rows per user). There is a provision to say that the "address for correspondence" is the same as the "permanent address". I don't want to replicate this data since a change has to be made in both the records. How do you model this in schema?
One table contains users, one table contains addresses, and another table represents the many-to-many relationship between users and addresses, with a column indicating the relationship type. The user will have two rows in the m-to-m table, one for each type of address, both pointing to the same identifier of the address in the addresses table.
Related
I have following two entities, where a person address is kept in a separate table because a person can have multiple addresses.
The mailing address however is one of the multiple addresses stored in address table, which is to be referred in person table.
Can following relationship exist?
The answer to your direct question is "Yes". However, you cannot declare the model only using create table because:
Declaring the foreign key address.person_id requires that the person table already exist.
Declaring the foreign key person.mailing_address requires that the address table already exist.
Hence, to implement the model, you need to use alter table to add one or both of the constraints after both tables are created.
Is this the model you want? One feature of an address is that multiple people can have the same address. Your model does not allow that. To handle this, you would typically have three tables:
Person
Address
PersonAddress
The third table has one row for each person/address pair. It can also have other information such as:
Type ("mailing" versus other types)
Effective and end dates.
Perhaps other information.
If you want to guarantee uniqueness of the "mailing" address in such a model, many databases support filtered unique indexes, to ensure there are no duplicate mailing addresses.
I'm not sure why you have person_id as an fk on address but that doesn't look correct. There are lots of correct ways to model this and the best one for you will depend on you particular circumstances - but a couple of options are:
If you know all the types of addresses there can be then add multiple address fk fields to the person e.g. billing address, shipping address, etc. This makes querying quick and simple but is inflexible: adding a new address type in the future is relatively complex to implement
Add an intersection table with fks for person and address and an address type field. This has a slight overhead when it comes to querying but has the advantage if being very flexible: adding a new address type is trivial
I am essentially trying to create a glorified contacts list using LibreOffice Base. Many of our contacts have multiple addresses (office, mailing, home), and sometimes multiple people have the same address.
I've created a simple contacts table with the Contact ID, Last Name, and First Name. I've created an address table with an Address ID, City, State, etc. I've also created a junction table with Contact ID and Address ID, and connected the three tables using the relationships tool.
Now I want to add everything into a single form. I watched this youtube video, which was very helpful, but I want to be able to add new cities instead of only selecting from a pre-established list. So I followed along with the video, but set the columns to "combo box" instead of "list box." However, when I try that I get an error message:
Error inserting the new record
SQL Status: 23000
Error code: -177
Integrity constraint violation - no parent SYS_FK_94 table: Address Table in statement [INSERT INTO "Contact-Address Junction" ( "Address ID","Contact ID") VALUES ( ?,?)]
I assume there's something obvious that I'm missing, but at this point I'm pretty stuck.
E: I took more screenshots to show the relationships, tables, and how things connect in the form:
In the video you cite, this is kind of silly as there is no need for a many to many relationship. The author could have simply added a Movie ID field to the genre Table, (so multiple genre records can point to each movie record).
I have a complex many-to-many contacts structure that I'm in the process of porting from MS Access to LibreOffice. It has 4 primary data tables: Groups, Address, Phones, and People. And there are 6 link tables to connect those primary tables: GroupAddress, GroupPhone, GroupPerson; AddressPhone, AddressPerson; and finaly PhonePerson. Unlike the video you cite above with only 2 fields, in my link tables there are 3 fields. GroupAddress for example has GroupAddressID (the unique id for the link table itself), GroupID (which points to the Groups table), and AddressID (which points to the addresses table). This allows any number of addresses per each group, and at the same time, any number of groups per each address.
So the whole thing has maximum data flexibility: For example it allows for unlimited number of people per group, each person can have an unlimited number of phones or addresses, each address an unlimited number of people, etc.
Implementing it in LO: Because in LO you can't edit a query based on more than one table (you can view it, but not edit it), like you can in Access, (and therefore you also can't build a form with a table that can edit a query based on more than one table), in LO this is not as clean as it is in Access.
In Access it works very well and the link tables manage themselves! In LO you have to manually edit the link tables in a separate table. I'm starting to think about how I might use some macros to improve on this, but for the moment it's bare bones.
To give you a better idea, the first form to edit Groups, which also edits the group's addresses, people, and phones (not just those tables, but also the links to those tables) looks like this:
Group lookup pulldown (used to find a group record)
(this is a drop down box with custom code that helps me find group records)
Group editing fields, e.g. Group name, category, url, etc
Then below that
Group-Person links table
Then to the right of that
Persons table (plural) - to create new person, then..
And below that
Person table (singular)
[pointed to by Group-Person link]
to view person pointed to.
Group-Address links || (similar structure to above)
(for example, when a business has two or more addresses)
Group-Phone links || (similar structure to above)
(this is for phone#'s that the group owns directly, not personal phones of the group's members, and not phones tied to specific addresses).
----------
Then there are 3 other similar forms,
one for Addresses w/ Person, Group & Phone links;
one for Phones w/ Group, Address & Person links;
and one for People w/ Group, Address and phone links;
Here is a screen shot of the first of the 4 editing forms, to edit the groups and the links associated with the group:
Hope this helps. I would be interested to see what you develop. Thanks.
Let's say I've 3 tables: enterprise, users, houses.
Everyone needs an address. What should I do?
Create a table address for everyone?
Create one unique table address?
Assuming that the first is "more" correct (cache, fragmentation, size, ...), how should I write it in plain SQL?
How do I create a "model" of the table address, and use it in custom tables (e.g. enterprise_address)?
* So when I change one field in the model, it gets replicated.
It appears you need every user to have an address. You have multiple ways to solve it.
Handle it in UI
Your users table will be just information about users (on address info here)
Create addresses table with addressid as primary key
Create many-to-many table/junction table called user_addresses that brings userid and addressid together
Ensure that your UI mandates address for each user
Tables
create table addresses (addressid int not null PK, line1, line2, city ...);
create table users (userid int not null PK, username, ...);
create table user_addresses (user_addressid int, userid int, addressid int, UK userid + addressid, FK to users, FK to addresses);
This allows a user to have multiple addresses. You have the flexibility of marking which one is primary.
Handle it in DB (and UI)
create table addresses (addressid int not null PK, ....);
create table users (userid int not null PK, username varchar(20), ..., addressid int not null, FK to addresses);
This allows one address per user.
and handle it also on the UI to ensure that address is supplied. Enter address into addresses first and then into users (make it an atomic process; use transactions!)
You can start with one these methods and analyze what your business needs are. Work with your DBA, if you have one, to see what their experience says about the business and previous DB designs similar to this.
Just from the three given tables I would assume that address is something you would want to put in either Houses or Users.
Depending on how much detail you want to keep track of in the Address it could be work making a separate table but there are a number of ways to go about this and the correct method depends solely on what you are trying to achieve.
Without knowing any of the required information all I can really advise is that you should aim to store the addresses as unique values. Once you have this you can assign each address to any other table you wish using a Foreign Key.
If you want to store multiple fields for the address then you will require a seperate table, if a single field will do then it could just as easily be added to the person or houses table.
One thing that would make a major difference to which way you would want to do this is the relationship between address and your other entities. For example if a user can have many addresses then you cant make it a part of the user table, and if an address can have multiple users assigned to it then it cant use a FK to represent its relationship to the users table.
One way you can do this is to make a relational table. So you make addresses and users seperate tables then have another table with just an id(pk) and 2 fks linking it to each of the other tables. This way you can have a many to many relationship if you wish.
First question: how many addresses per enterprise/user/house? If there are multiple addresses per entity, that leads you to want a separate address table, possibly with an address type.
Examples of multiple address situations:
Multiple locations
Ship-to addresses
Physical vs. PO Box
If you are going to assert that an entity can only have one address, then you probably prefer making the address part of the entity row, for simplicity. However, there can be reasons not to do that; for example, table width (number of columns in the table).
If you have multiple addresses per entity, typically you will use a foreign key. The entity should have an abstract key: some kind of ID. This will either be an integer or, in SQL Server, it could be a uniqueidentifier. The entity ID will be part of the key for the address.
Ok, I found the answer to postgresql: use INHERITS
e.g. CREATE TABLE name () INHERITS (table_model)
Thank you all for the answers.
Suppose i have a table with 3 fields
Person_id, Name and address. Now the problem is that a person can have multiple addresses. and the principle of atomic values says that data should be atomic.
So then how am i suppose to store multiple addresses for a single person ?
You're supposed to create an ADDRESS table that has a foreign key linking it to a PERSON record, i.e. PERSON_ID. This is the "relational" component of a relational database, and it's why it's more flexible than a flat file (which is like a single table).
Put adresses in a second table, give each adress a "Person ID", so that mutiple rows in the adress-table can referr to on person.
I would suggest adding a address type to the address table to identify which type of address it is (Home, Vacation, Office), etc. Something like: AddType that refers to a list table where more types could be added down the road.
i have a table Students which contains the following colums:
Id,FirstName,LastName,Adress.
The colum Adress will contain just the street adress.
the question is: will it be better for the database optimization to isolate the column Adress in a different table?
Yes. If you seperate it into another table, you can have more than one address per person. If you seperate it to two different tables, an Address table and a StudentAddress table to map the two together, you can make sure that a single address is shared between people or even track a history of addresses for one person. Further, in a seperate table you can break the address down into columns so that you can easily search by City or Province or Country.
You can't do any of that putting an Address into a single column with the Student table.
It depends on how you are going to treat that Address. If you will need to treat it as different entity, i.e. link single address to several Students or vice versa e.t.c., then you should do normalization.
If address is only attribute of entity student then leave it as is.
For full proper data structures to manage addresses: THe Data Model Ressource BOok, Volume 1. It is a LOT more complicate to get right than you think.