Hi have a quick question I've been on this question for some time now and I don't know this answer to this question.
"which of the following database types requires you to avoid the three anomalies"
A. Management Information Systems
B. Knowledge Management Systems
C. Warehouse
D. Transaction Processing System
You are creating a small database for a jewelry store. You schedule a meeting with the owner to discuss the project and get an idea of what the database will require. The owner mentions how he would like the database to be shared on his network in the shop, produce numerous reports, include security and be visible on his website. Before you begin drafting your first model, you take a look at your schedule and realize that you may not have time to add the security and the web site visibility. What do you need to construct for the owner so that he knows what you are able to do and not to do with regards to this project?
A. Security Requirements
B. Problem Statement
C. Objectives
D. Scope
You are designing a database for a jewelry store and need to create an entity called ORDER. Within this entity you need an attribute called OrderDate and ShipDate. When the user enters the ShipDate, it cannot be a date that occurs before the OrderDate. Which constraint would be the best to place on this attribute?
A. Primary Key
B. Unique
C. Foreign Key
D. Check
If anybody can help it would be great these are the only question that I'm really stuck on.
For the third question you would add a check constraint to ensure the ship date cannot be before the order date.
Related
What is the best-practice for maintaining the integrity of linked data entities on update?
My scenario
I have two entities "Client and
Invoice". [client is definition and
Invoice is transaction].
After issuing many invoices to the
client it happens that the client
information needs to be changed
e.g. "his billing address/location
changed or business name ... etc".
It's normal that the users must be
able to update the client
information to keep the integrity of
the data in the system.
In the invoice "transaction entity"
I don't store just the client id but
also all the client information related to the
invoice like "client name, address,
contact", and that's well known
approach for storing data in
transaction entities.
If the user created a new invoice the
new client information will be
stored in the invoice record along
with the same client-id (very
obvious!).
My Questions
Is it okay to bind the data entities
"clients" from different locations
for the Insert and the update?
[Explanation: if I followed the
approach from step 1-4 I have to
bind the client entity from the
client table in case of creating new
invoice but in case of
updating/printing the invoice I have
to bind the client entity from the
invoice table otherwise the data
won't be consistent or integer...So
how I can keep the data integrity
without creating spaghetti code in
the DAL to handle this custom
requirements of data binding??]
I passed through a system that was
saving all previous versions of an
entity data before the update
"keeping history of all versions".
If I want to use the same method to
avoid the custom binding how I can
do this in term of database design
"Using MYSQL"? [Explanation: some
invoices created with version 1.0 of
the client then the client info
updated and its version became 1.1
and new invoices created with last
version...So is it good to follow
this methodology? and how I should
design my entities/tables to fulfil the requirements of entity
versioning and binding?
Please provide any book or reference
that can kick me in the right
direction?
Thanks,
What you need to do is leave the table the way it is. You are correct, you should be storing the customer information in the invoice for history of where the items were shipped to. When it changes, you should NOT update this information except for any invoices which have not yet been shipped. To maintain this type of information, you need a trigger on the customer table that looks for invoices that have not been shippe and updates those addresses automatically.
If you want to save historical versions of the client information, the correct process is to create an audit table and populate it through a trigger.
Data integrity in this case is simply through a foreign key to the customer id. The id itself should not ever change or be allowed to change by the user and should be a surrogate number such as an integer. Becasue you should not be changing the address information in the actual invoice (unless it has not been shipped in which case you had better change it or the product will be shipped to the wrong place), this is sufficent to maintain data integrity. This also allows you to see where the stuff was actually shipped but still look up the current info about the client through the use of the foreign key.
If you have clients that change (compaies bought by other companies), you can either run a process onthe server to update the customer id of old records or create a table structure that show which client ids belong to a current parent id. The first is easier to do if you aren;t talking about changing millions of records.
"This is a business case where data mnust be denormalized to preserve historical records of what was shipped where. His design is not incorrect."
Sorry for adding this as a new response, but the "add comment" button still doesn't show.
"His design" is indeed not incorrect ... because it is normalized !!!
It is normalized because it is not at all times true that the address corresponding to an invoice functionally depends on the customer ID exclusively.
So : normalization, yes I do think so. Not that normalization is the only issue involved here.
I'm not completely clear on what you are getting at, but I think you want to read up on normalization, available in many books on relational databases and SQL. I think what you will end up with is two tables connected by a foreign key, but perhaps some soul-searching per previous sentence will help you clarify your thoughts.
I am a developer and have never worked on DB before (designing a DB). I am designing a database for an employee management system which is a Node.js + Express application using MySQL as its DB.
I already have the required tables, columns sorted out but there are still few unknowns I am dealing with. This is my plan so far and I need your input on it.
The end users using this application will be small - mid size companies. The companies won't be sharing the tables in the database. So if there is a table named EmployeeCases I plan to create a new EmployeeCases table for each existing company or a new one who signs up for this application. I am planning to name the table as EmployeeCases_989809890 , where "989809890" will be the company id (or customer id). So if we have 3-4 companies who signed up for us, then all the tables (at least the ones which a company uses) will be recreated and named as TableName_CompanyId. My questions, is this a good way to go? Is there a better way?
All the employee's data is held by the Employee table, including their login and password. Now each Employee table in DB will be named as Employee_CompanyId (as per my plan above). My question is, when an employee logs in, how will I know which Employee table to query to? Or should I remove the login from the Employee table and create a universal Users table where all the employees will be stored? The Users table will also have the CompanyId as one of its column and I will read the CompanyId from there which will be used to query other tables.
Any reference, website or blogs on this type of design will be appreciated.
Thanks.
I don't recommend this approach, I think you should either:
A) Put all the information in the same tables and have a companyId column to sort them out
OR
B) Have separate databases for each company and use the appropriate database using the code.
The thing is, with your approach, you'll have a hard time maintaining your application if you have multiple copies of the same table with different names. If you decide to add a column to one of the tables, for instance, you will have to write as many SQL scripts as you have table instances. You'll also have a bad time with all of your unique identifiers.
Here are some advantages/disadvantages of each design:
A) Put all the information in the same tables and have a compagnyId column to sort them out
Advantages:
Simplest
Allow usage of foreign key / constraints
Great for cross / client data extraction
Disadvantages:
Not portable (a client can't just leave with his/her data)
Can be perceived as less secure (I guess you can make the case both ways)
More likely to have huge tables
Does not scale very well
B) Have separate databases for each company and use the appropriate database using the code.
Advantages:
Portable
Can be perceived as more secure
Disadvantages:
Needs more discipline to keep track of all the databases
Needs a good segregation of what's part of your HUB (Your application that tracks which client access which database) and that's part of your client's database.
You need a login page by company (or have your clients specify the company in a field)
An example of an application that uses this "two-step login" is Slack, when you sign-in you first enter your team domain THEN your user credentials.
I think Google Apps for Work as the same approach. Also, I think most CRM I worked with has a separate database for their clients.
Lastly, I'd like to direct you to this other question on stackoverflow that links to an interesting example.
You shouldn't split your tables just because companies won't share their information. Instead, you should have a companyId column in each table and access to the relevant data for each query. This should be implemented in your backend
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
About the Program
Excuse the vague title, but I'm rather new to mySQL and databases. I'm a developer in VB.NET and need to create a program that connects to a database. The program is a guide for a game, and part of the program gives you directions to your next objective when you select a mission. For example, from the application (made in WinForms), you select a "mission" from a combo-box control, and a Textbox will populate according to the objectives in the database. A further example could be displayed as this:
You Select "The First Misson" from the Combo-Box control.
The Textbox Control now contains a numerical list of objectives in order, like so:
Locate John.
John asks you to find a weapon
Give the weapon to John
Help John fight off the monster
John asks you to heal him with a potion
Help John reach the portal at the end of the tunnel
Speak to John about your rewards
Now, the question is how may I display a list like the one above using a database? I was reading up on normalization; however, I still do not see how this may be done.
This is an example of the application (just a mock up, but very similar):
Now say the user selected a misson from the Combo-box located at the top of the application. The application would populate like so:
Ideas via Normalization
I understand I could create two seperate tables containing data relating to the misson. For example, I might be able to create a table called "Stages", and a table called "Missons", but I see this as inefficient, not to mention populating the database itself would take ages. I quickly found that you could not (obviously) store a list in a single cell. So being just a programmer, and not someone who works with databases, I this is very frustrating.
(If it may help, I can also alter the application in which is retrieving data from the database to allow a list to be displayed a different way.)
The Overall Issue
There may be "work-arounds" to address this problem, but I don't know what to do. I do not understand how you could display such data using a database. I understand how you connect to the database and retrieve data using queries, just not with a list. Also, an elaborate answer would be much appreciated for a newbie at this like me.
From what I read, you seem to be primarily stuck up on database relationships. No worries! When you want a "list" in a database, this means you are looking for a one-to-many relationship, or a many-to-many relationship. Here is a brief tutorial that explains the differences between these types of relationships.
One of the first steps in database design is to define your entities (i.e. your tables.) In general, your entities will typically be major nouns from your business problem. In this case, you clearly have the following entities (tables): Mission and Objective. The only other data present on your form is a textbox for mission location and a textbox for mission requirements. Both of these fields can be single properties of the Mission table.
The next step is to define your entity relationships. You might define your relationships as follows:
A Mission has one-to-many Objectives
An Objective belongs to one Mission
Finally, lets list out our known properties:
A Mission has a name (text)
A Mission has one location (text)
A Mission has one requirement (text)
Now we can create a basic database schema. So. What would this look like?
Each table has it's own primary key, denoted by the key image in the picture above. The primary key is a unique identifier for a row of data and is usually represented by an integer. The Objective table also has a foreign key, the missionID field. This is how the one-to-many relationship is defined between these tables.
This way, if we create a Mission with missionID 1, we can assign this missionID to many Objectives. Just like a list, but in the syntax of a relational database. See the images below:
In order to retrieve information about both entities at once, you might use a JOIN query. Hope this helps!
You probably should read up on entities and relationships.
Entities are database parlance for things like a game, a mission, a requirement, and a player (a person).
Relationships are database parlance for statements like
each game has one or more missions in it
each mission has one or more requirements in it, displayed in order
zero or more players can be playing each game.
Each table in your rdms is a collection of instances of a particular entity. So, you'll have a requirement table, for example, that will record the following information for each requirement, each in its own row of the table, for example
game_id the game for which this is a requirement
mission_id the mission for which this is a requirement
requirement_ordinal 1,2,3,4 etc for which requirement in sequence this one is.
description the text describing the requirement: "Speak to John about normalizing your rewards."
You may declare that a particular combination of the first three items uniquely identifies each requirement, which is to say that (game_id,mission_id,requirement_ordinal) is the primary key for the requirement table.
Desktop apps like MySQL Developer and MS Access have graphic design tools that let you draw this stuff in a charts. Here's a writeup. http://docs.oracle.com/cd/A87860_01/doc/java.817/a81358/05_dev1.htm This business of entity-relationship modeling can get very elaborate and abstruse, so be careful not to dive in too deep.
Working this all out is what database design is about. I can't design this whole thing for you, but I can offer you some jargon and a conceptual framework to help you figure out how to search for it.
currently Im working on a project that, at first glance, will require many tables in a database. Most of the tables are fairly straightforward however I do have an issue. One of the tables will be a list of members for the website, things like username, password, contact info, bio, education, etc will be included. This is a simple design, however, there is also a need for each member to have their availability entered and store in the database as well. Availability is defined as a date and time range. Like available on 4/5/2011 from 1pm to 6pm EST, or NOT available every friday after 8pm EST. For a single user, this could be a table on its own, but for many users, Im not sure how to go about organizing the data in a manageable fashion. First thought would be to have code to create a table for each user, but that could mean alot of tables in the database in addition to the few I have for other site functions. Logically i could use the username appended to Avail_ or something for the table name ie: Avail_UserBob and then query that as needed. But im curious if anyone can think of a better option than having the potential of hundreds of tables in a single database.
edit
So general agreement would be to have a table for members, unique key being ID for instance. Then have a second table for availability (date, start time, end time, boolean for available or not, and id of member this applies to). Django might sound nice and work well, but i dont have the time to spend learning another framework while working on this project. The 2 table method seems plausable but Im worried about the extra coding required for features that will utilize the availability times to A) build a calender like page to add, edit, or remove entered values, and B) match availabilities with entries from another table that lists games. While I might have more coding, I can live with that as long as the database is sound, functional, and not so messy. Thanks for the input guys.
Not to sound like a troll, but you should take a look into using a web framework to build most of this for you. I'd suggest taking a look at Django. With it you can define the type of fields you wish to store (and how they relate) and Django builds all the SQL statements to make it so. You get a nice admin interface for free so staff can login and add/edit/etc.
You also don't have to worry about building the login/auth/change password, etc. forms. all that session stuff is taken care of by Django. You get to focus on what makes your project/app unique.
And it allow you to build your project really, really fast.
djangoproject.org
I don't have any other framework suggestions that meet your needs. I do... but I think Django will fit the bill.
Create a table to store users. Use its primary key as foreign key in other tables.
The databases are written to hold many many rows in a table. There are not optimized for table creation. So it is not a good idea to create a new table for each user. Instead give each user an unique identifier and put the availability in a separate table. Provide an additional flag to make an entry valid or invalid.
Create a table of users; then create a table of availabilities per user. Don't try to cram availabilities into the user table: that will guarantee giant grief for you later on; and you'll find you have to create an availabilities table then.
Google database normalization to get an idea why.
Take it as truth from one who has suffered such self-inflicted grief :-)
What is the best-practice for maintaining the integrity of linked data entities on update?
My scenario
I have two entities "Client and
Invoice". [client is definition and
Invoice is transaction].
After issuing many invoices to the
client it happens that the client
information needs to be changed
e.g. "his billing address/location
changed or business name ... etc".
It's normal that the users must be
able to update the client
information to keep the integrity of
the data in the system.
In the invoice "transaction entity"
I don't store just the client id but
also all the client information related to the
invoice like "client name, address,
contact", and that's well known
approach for storing data in
transaction entities.
If the user created a new invoice the
new client information will be
stored in the invoice record along
with the same client-id (very
obvious!).
My Questions
Is it okay to bind the data entities
"clients" from different locations
for the Insert and the update?
[Explanation: if I followed the
approach from step 1-4 I have to
bind the client entity from the
client table in case of creating new
invoice but in case of
updating/printing the invoice I have
to bind the client entity from the
invoice table otherwise the data
won't be consistent or integer...So
how I can keep the data integrity
without creating spaghetti code in
the DAL to handle this custom
requirements of data binding??]
I passed through a system that was
saving all previous versions of an
entity data before the update
"keeping history of all versions".
If I want to use the same method to
avoid the custom binding how I can
do this in term of database design
"Using MYSQL"? [Explanation: some
invoices created with version 1.0 of
the client then the client info
updated and its version became 1.1
and new invoices created with last
version...So is it good to follow
this methodology? and how I should
design my entities/tables to fulfil the requirements of entity
versioning and binding?
Please provide any book or reference
that can kick me in the right
direction?
Thanks,
What you need to do is leave the table the way it is. You are correct, you should be storing the customer information in the invoice for history of where the items were shipped to. When it changes, you should NOT update this information except for any invoices which have not yet been shipped. To maintain this type of information, you need a trigger on the customer table that looks for invoices that have not been shippe and updates those addresses automatically.
If you want to save historical versions of the client information, the correct process is to create an audit table and populate it through a trigger.
Data integrity in this case is simply through a foreign key to the customer id. The id itself should not ever change or be allowed to change by the user and should be a surrogate number such as an integer. Becasue you should not be changing the address information in the actual invoice (unless it has not been shipped in which case you had better change it or the product will be shipped to the wrong place), this is sufficent to maintain data integrity. This also allows you to see where the stuff was actually shipped but still look up the current info about the client through the use of the foreign key.
If you have clients that change (compaies bought by other companies), you can either run a process onthe server to update the customer id of old records or create a table structure that show which client ids belong to a current parent id. The first is easier to do if you aren;t talking about changing millions of records.
"This is a business case where data mnust be denormalized to preserve historical records of what was shipped where. His design is not incorrect."
Sorry for adding this as a new response, but the "add comment" button still doesn't show.
"His design" is indeed not incorrect ... because it is normalized !!!
It is normalized because it is not at all times true that the address corresponding to an invoice functionally depends on the customer ID exclusively.
So : normalization, yes I do think so. Not that normalization is the only issue involved here.
I'm not completely clear on what you are getting at, but I think you want to read up on normalization, available in many books on relational databases and SQL. I think what you will end up with is two tables connected by a foreign key, but perhaps some soul-searching per previous sentence will help you clarify your thoughts.