1- Message belongs to name, Name belongs to Email and email belongs to phone number
2- Message belongs to email, email belongs to name and name belongs to phone number
3- many messages can point to a single email and name and phone number.
Message belongs to email, message belongs to name, message belongs to phone number.
Or is there any better structure which would satisfy normalization.
The purpose of this from is to store data so that the telecaller can later contact the person who contacted via email and phone number
You are not phrasing your requirements properly. So we cannot provide a precise solution.
Entity
Instead of thinking about columns and fields, think about entities. What are the real-world things you are trying to track in your database and app.
If doing an appointment scheduling system for an veterinary practice, you have several entities: Customer, Animal, Doctor, MedicalAssistant, Appointment/Visit.
If your tracking employees communicating, you have Employee and Message.
Attribute
After identifying entities, you identify attributes. What aspects of each of your entities do you care to track in your database and app? For example, your employee’s have a height and a hair color as attributes, but those two are irrelevant to your messaging app. On the other hand, each employee has conduits of communication as attributes, perhaps having an email address, an office phone, and a personal mobile phone, as examples. Again, you must ask which of those you care to track.
Relationship & Cardinality
If you want to look up the employee's email address or phone, but track messages without regard to mode of communication, then we have two tables. The relationship is that each employee can have zero, one, or more messages, and each message must have exactly one employee. This quantifying of related rows between tables is known formally as cardinality.
In my ASCII-art equivalent of crows-feet ERD diagramming:
[employee]-1-----0-1-<[message]
As for columns on those tables:
Current name, current email address, and current office phone number extension are all attributes (columns) on the employee table.
The message table has a column content.
Keys
The employee table also must have a primary key column. The primary key is usually an identity column (auto-incrementing sequence of integer numbers) or a UUID.
The message table as wall carries a primary key column. In addition, the message table must have a foreign key column. The foreign key column contains the value of the primary key of the employee to whom the message was sent.
Related
I've got a problem with trying to transfer a data model to a data vault. I've tried a lot already but cannot figure out the correct way of identifying the hubs, links and satellites for this part of the diagram.
What is shown is a employee that works at a certain store. The issue here is the the employee_id on it's own does not uniquely identify a employee. Two employees can have employee_id 1 as long as they are working in different stores.
What would be the correct method of modelling this (what should be the hub, links and satellites)?
A business key can have more than one field.
In this case, the business key can be the store and the employe id (if you can have another field than an ID that uniquely identify the store and the employee that the end user can remember, it will be better).
I want to create a database following the following specifications:
A well known bicycle company stores its data in a special database.
Company has customers and
products.
All customers have a unique customer_id.
Customers are categorized as foreign customers or domestic customers. A customer must
be foreign or domestic, and can not belong to both of the categories at the same time.
Foreign customers are identified by their unique id, currency, company name and address
composed of city state and zipcode.
Domestic customers are identified by their unique id, name and address. Domestic
customers may have more than one address information.
Products are identified by unique product_id, model, type and price.
Only two type of products are produced in this company. These product types are Bike and
Mountain Bike.
Each bike has color and cycle attributes.
Each mountain bike has cycling team attribute.
A product may belong to at least one of this types. Moreover it may belong to both of them
at the same time.
Customers may request products. And a product may be requested by more than one
customer, also it may not be requested by any customer at all.
When a product is requested or ordered by a customer; request id, request type and request
content information is stored.
I asked about the composite key address and I got 2 possible choices right now: Create a table for address or create city, state and zipcode keys and add a constraint named address. However, it says that a domestic customer may have more than one address information. I don't know how to do that.
I am working on a bank application in which a customer can open multiple accounts for different product types like: Insurance, Investment and annuity etc.
Each customer has a profile and we are saving that information in 12 different tables such as : Personal,Contact,Address,Affiliation,Financial,Investment,Asset,Liability,NetWorth and so on.
Now to open each account we have to collect and save same kind of information like for customer profile but we cannot overwrite the customer profile with that as we have to keep track of each accounts information when its submitted to the point when it get opened.
So in terms of solution we think either to have replica of these 12 tables for each account or to save the JSON for each table in one table only which has 12 columns for each of above table and populate UI with that.
Can somebody if have prior experience suggest us how to do this in best way.
I would determine which information will not change between accounts. For example, name, birthday, ssn, etc. These constant fields can form a table called customers. If there are no constant fields, then you can use a placeholder id, which simply helps to associate accounts to the same user.
I would also create a table for Accounts and use the account_id as a foreign key for all your customer information that may change between accounts. Each row in the Accounts table will be owned by a customer from before.
So the relationship between customers and accounts would be one to many, and the relationship between accounts and "account specific customer info" would be one to one.
I am creating a windows forms application that must control the entry and exit of people in an office building. These people may be visitors or employees, and everybody must use an access card at the building entrance. A card will be programmed temporarily when the person is a visitor, and the employees should use their own cards. My doubt is about my database. Is there a way to do this nicely? The cards (no matter if it is an employee or visitor ) has a strong key to the ratchet can identify it wich comes from the manufacturer of turnstiles and I can't change it. So, my structure is:
In my database, I have a table where I keep the cards. When someone try to get inside the building, the turnstile sends to my system the date and time of access and the card code. Now I do not know how to separate the employees and visitors. Should I have a separated flow table to employees and visitors? For the employees flow table, I get the employees card from the card table using the same ID. In the visitor flow table, I need to know who is the visitor using the temporary card (the key to the temporary card never changes, so I can not rely on me only in the key). Or should I only have a flow table with a Visitor_ID and Worker_ID column , one of which will always be null (so I know if it was an employee or a visitor by the field with a value).
Can anyone tell me which of the two is more applicable and why?
Employees and visitors are both people. Specifically people that may (or may not) have an access card assigned to them.
I would have one People table that has a foreign key relationship to the AccessCard table. If you only care about whether the person is an employee or visitor, but the information you store is otherwise identical, a boolean column is fine. If your system stores additional information for employees and/or visitors, create an Employees and Visitors table, and have a foreign key relationship from People to each of those.
I would create single table to store both employee and visitor then add an extra column for Type(E, V).
I need to design a DB structure that will keep records of Customer Communication information and preferred communication type for certain situations. Basic design will include
Communication Records: Each customer may have one or more phone number, address, e-mail address etc. recorded in the database. Or they may not have any defined record for some of these cases (like he may have a phone number but not have any address defined in the system)
Record sub-types: A phone number can be a line or a GSM phone number. Address can be home or work address etc.
Customer Preferences: Customers will set their preferred type of communication for some situations. Situations will include:
Sending single-usage password for login (just mobile phones)
Sending billing information ( may be mobile phone number, e-mail address or normal address.)
So, some preferences will accept a certain communication type (Only phone number), or sub-type (only GSM phone number) while some may accept more than one type (address or e-mail)
I am trying to make the DB design to handle this and it must be an optimized structure.
I am having hard time about deciding the structure. Creating a single table for all communication records that have a type (phone) and a sub-type (GSM) will have many unnecesarry fields for each record (since an address will contain DB fields like city and country, while a phone record will not, while it needs number field) Creating seperate tables for each is better, but this time I will have problems in defining preferences table because some preferences will only accept a sub-type (like GSM phone) while some will accept more than one type (like address or e-mail)
What will be the best database design approach for a such need? DBMS has not been decided yet but it might be Postgresql or Oracle.
Address needs to be in a separate table, because as you said, there are many columns to an address. You can put a flag in the Address table to differentiate between a work address and a home address, if necessary.
Address
-------
Address ID
Street
City
...
The Address ID is an auto incrementing integer or long. It's the primary (clustering) key.
The remainder of the communication records can go in a Contact table. The table would look like this:
Contact
-------
Contact ID
Contact Type (Land line phone, email, cell phone, etc.)
Contact Information
The Contact ID is an auto incrementing integer or long. It's the primary (clustering) key.
The Contact Information is a varchar that holds the email address or the telephone number.
The Preference table would look like this:
Preference
----------
Preference ID
Preference Order
Customer ID
Preference Type (address or contact)
Address ID
Contact ID
The Preference ID is an auto incrementing integer or long. It's the primary (clustering) key.
The Preference Order defines the order of the preferences. Email first, then phone, as an example.
The Customer ID is a foreign key back to the Customer table.
Either the Address ID or the Contact ID would be a foreign key back to the Address table or the Contact table, respectively.
Pick up a good data model pattern book, such as by Hay, Silverston or Fowler's "Analysis Patterns".
You want to abstract Email, Phone, Mailing Address, and Web Address into an abstract Address type, so that you can point a single foreign key to any kind of address. Use Table Inheritance.
GSM Number is not a subtype of Phone Number, because you should only use inheritance for things that never change, and someone's phone number can be moved from a cell to landline.
create table address (
id serial primary key,
type smallint not null references address_type(id) -- elided
);
create table address_phone_number (
id int primary key references address(id),
phone_number text
);
/*
add subtype tables for email, web, mailing...
*/
create table party (
id serial primary key,
type int not null references party_type(id), -- elided
name text not null
);
create table party_address (
party_id int not null references party(id),
address_id int not null references address(id),
role char(2) not null, -- examples: wf=work fax, ho = home
primary key party_id, address_id, role)
);
you could subtype part_address to say party_address_phone_number to add a telephone extension