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.
Related
We had an MS Access guru at our company who left for another position. Before she left she gave me a quick introduction on how to create queries from a sql server. I am really struggling with this and as I have no one to turn to at our company I was hoping you guys could help.
Hope you can help!
Thanks!
Well, keep in mind that when you build a query, it DOES NOT necessary mean that a enforced relationship exists here. (it might).
Further more, if you imported the tables, then again its doubtful that relations are defined in Access unless you use the relationships window to "enforce" such relationships.
However, when building a query? We will often join on two fields. When you build a query in the query builder, you are free to "make up" any kind of join you want.
Say I was given two different spreadsheets. One had some people, and another had a list of hotels.
Ok, so say we want to generate a list of all people in the same city as the hotels.
You might join between table "People" and say Hotels with city.
however, WHAT happens if there is more then one state with the same City name?
Well, then just join on City AND State!!!
So you get this:
So I not have some related tables here. I just feel like and want to, and need to join the two tables of data.
As such, we never cared or setup or "had" some relationship defined, but all we care about is creating and building a working query.
So, don't confuse the simple act of building some query with that of having setup a corrrect relatonships between tables.
For a working application? Yes, you most certainly will setup relatonships.
So, if you setup relatonships correctly, then you not be able to say add a customer "invoice" reocrd without FIRST having a customer record. You don't have to do this, but it is a very good idea for a working applicaton.
However, when dealing with imported data? You often may not have an pre-defined relationships.
Now, of course in "most" cases, a query that involves multiple tables will in near all cases "follow" what you defined as relationships in the relationships window but it not necessary a requirement at all.
As noted, when building a working application? Then yes, of course you want to setup the relatonships BEFORE you start adding data.
But for general data processing, and creating queries against say different tables of data you are slicing and dicing and working with?
You are free to cook up and draw lines between the tables in the query builder, and as such, often such quires will have zero to do with the relationships you defined, or in fact even when you don't have any relationships defined at all.
That above People and the list of hotels is a great example. I mean, it rather cool that I simple joined on both City and State, and did not have to write one line of data processing code for my desired results
(a list of people in cities that live in the same city as my hotel list).
So don't confuse what we call "referential integrity" and defined relationships. We define these relationships so it becomes impossible for you the developer to add a customer invoice without first having added the customer. And it also means that you, your code, or even a editing the tables directly will not allow this to occur.
However, when dealing with just reporting, or importing data to work on? Well, then often we will not have any relationships defined, but that sure does not stop us from firing up the query builder and drawing join lines between tables.
Between two given Tables you can have one relationship involving two (of more) fields or two (or more) relationships each involving one field. Both cases are possible and have different implications.
The first case, as the first commenter pointed out, is typically used when you have a compound key in the master Table of the relationship.
The second case is typically used when you have two candidate keys in the master table, each of which is used as a master field in each of the two independent relationships.
In Ms-access the case of two independent relationships may be identified because it implies two table-boxes for the same table in the relationships pane.
We're building a new piece of software for our company, where we want to manage our inventory.
The goal for the tool is to be customizable by the customer.
My part is mostly on the DB side. We have chosen MariaDB as our DB engine, and while we are working with the rather static functionality of a relational DB, we want to realize a rather dynamic solution.
Our chief programmer has explained to me the basics of the concept I shall implement into our DB:
We want a table which basically just consists of other tables.
Lets call it "maintable".
Maintable shall then reference its "attributes", which are the other tables.
For example, maintable references "Workstations".
"Workstations" then contains attributes like CPU, RAM, Drives, PSU etc..
And now comes the part which I didn't completely understand. The actual VALUES to these attributes in "Workstations" shall not be inserted into "Workstations". Instead, they are packed into another (junction?) table.
The reason for this approach is that the customer shall be able to customize the DB to his needs.
When the customer wants to add another attribute, he shall be able to do so. For example, if a new PSU now requires another attribute for an additional serial number, then the customer shall be able to simply create this new attribute in the front-end input form and then persist it to the DB.
If someone could point to good tutorials explaining this type of DB concept, then I would be glad as well! :=)
In my current design, I have app_group, student and group_article:
To structurally ensure that a group_article is only associated with a student from that same group, the foreign keys "publisher" and "app_group" are taken from the join entity group_member (1) as opposed to having them issued from student and app_group individually. This way, someone with the right to insert new records into the database cannot introduce incoherent data such as adding an article that have been written by a student that isn't even in that group which would be poor design. Now, I want generalize this approach into multiple students or multiple groups. I now have group_message, group_message_in and group_message_out which is an inheritance chain (group_message is the base which is an abstract entity in Symfony, and both group_message_in and group_message_out extend it):
Initially, I was planning to embed the group foreign key on the base class (group_message) and have the sender/recipient (respectively on group_message_out and group_message_in) be taken from student directly:
However, this will leave the database vulnerable to incoherence as per the first example, eg: student from group A can be associated with a message that targets student from group B which is not desirable (only students from the same group can exchange group_message).
I'm well aware that I can amend this risk in code but I want a similar solution to (1) and to know if this is achievable with Doctrine since MySQL itself might have ways of solving a similar problem that aren't supported by Doctrine.
A relational solution to your problem would look something like this:
The integrity that you seek would be achieved by the PK-FK relationships and by assigning a student to a group using the groupName colums.
Your question then becomes something like "How can I use Doctrine to do the same thing?"
To the best of my knowledge Doctrine uses a set of PHP libraries to create what its proponents call a "persistence layer" that stores what it calls "Entities". With Doctrine, the term "Entity" is a synonym for "Class" in the OO paradigm.
In other words Doctrine stores classes in the data layer.
And now we can see the problem.
A relational schema is a structure of relations which is a completely different kind of artefact than a collection of classes.
The OO/Relational divide has been called an "impedance mismatch". Unfortunately this term obscures more than it reveals.
To quote from the Wikipedia article: "There have been some attempts at building object-oriented database management systems (OODBMS) that would avoid the impedance mismatch problem. They have been less successful in practice than relational databases however, partly due to the limitations of OO principles as a basis for a data model."
I suggest that you also review Ted Neward's article "The Vietnam of Computer Science."
This new answer shows the object-role model, the relational schema that it generates and the logic that is implied by the new constraint (shown by the red arrow)
The object- role model.
This is the logic that is asserted by the fact type Student(.id) is a member of Group(.name)
Now as the domain expert, you can read this verbalization and tell me whether it is True or False in your domain.
Please note that all I did as the modeler, was to change the constraint (shown by the red arrow) and the ORM tool called NORMA generated the new verbalization that you see here.
When the domain expert agrees that the model conforms to the requirements then it takes a few seconds to generate the SQL DDL that can then be used to create a new database schema in an RDBMS.
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.
this is a follow-up question on my previous one.We junior year students are doing website development for the univeristy as volunteering work.We are using PHP+MySQL technique.
Now I am mainly responsible for the database development using MySQL,but I am a MySQL designer.I am now asking for some hints on writing my first table,to get my hands on it,then I could work well with other tables.
The quesiton is like this,the first thing our website is going to do is to present a Survey to the user to collect their preference on when they want to use the bus service.
and this is where I am going to start my database development.
The User Requirement Document specifies that for the survey,there should be
Customer side:
Survery will be available to customers,with a set of predefined questions and answers and should be easy to fill out
Business side:
Survery info. will be stored,outputed and displayable for analysis.
It doesnt sound too much work,and I dont need to care about any PHP thing,but I am just confused on :should I just creat a single table called " Survery",or two tables "Survey_business" and "Survey_Customer",and how can the database store the info.?
I would be grateful if you guys could give me some help so I can work along,because the first step is always the hardest and most important.
Thanks.
I would use multiple tables. One for the surveys themselves, and another for the questions. Maybe one more for the answer options, if you want to go with multiple-choice questions. Another table for the answers with a record per question per answerer. The complexity escalates as you consider multiple types of answers (choice, fill-in-the-blank single-line, free-form multiline, etc.) and display options (radio button, dropdown list, textbox, yada yada), but for a simple multiple-choice example with a single rendering type, this would work, I think.
Something like:
-- Survey info such as title, publish dates, etc.
create table Surveys
(
survey_id number,
survey_title varchar2(200)
)
-- one record per question, associated with the parent survey
create table Questions
(
question_id number,
survey_id number,
question varchar2(200)
)
-- one record per multiple-choice option in a question
create table Choices
(
choice_id number,
question_id number,
choice varchar2(200)
)
-- one record per question per answerer to keep track of who
-- answered each question
create table Answers
(
answer_id number,
answerer_id number,
choice_id number
)
Then use application code to:
Insert new surveys and questions.
Populate answers as people take the surveys.
Report on the results after the survey is in progress.
You, as the database developer, could work with the web app developer to design the queries that would both populate and retrieve the appropriate data for each task.
only 1 table, you'll change only the way you use the table for each ocasion
customers side insert data into the table
business side read the data and results from the same table
Survey.Customer sounds like a storage function, while Survey.Business sounds like a retrieval function.
The only tables you need are for storage. The retrieval operations will take place using queries and reports of the existing storage tables, so you don't need additional tables for those.
Use a single table only. If you were to use two tables, then anytime you make a change you would in effect have to do everything twice. That's a big pain for maintenance for you and anyone else who comes in to do it in the future.
most of the advice/answers so far are applicable but make certain (unstated!) assumptions about your domain
try to make a logical model of the entities and attributes that are required to capture the requirements, examine the relationships, consider how the data will be used on both sides of the process, and then design the tables. Talk to the users, talk to the people that will be running the reports, talk to whoever is designing the user interface (screens and reports) to get the complete picture.
pay close attention the the reporting requirements, as they often imply additional attributes and entities not extant in the data-entry schema
i think 2 tables needed:
a survey table for storing questions and choices for answer. each survey will be stored in one row with a unique survey id
other table is for storing answers. i think its better to store each customers answer in one row with a survey id and a customer id if necessary.
then you can compute results and store them in a surveyResults view.
Is the data you're presenting as the questions and answers going to be dynamic? Is this a long-term project that's going to have questions swapped in and out? If so, you'll probably want to have the questions and answers in your database as well.
The way I'd do it would be to define your entities and figure out how to design your tables so relationships are straightforward. Sounds to me like you have three entities:
Question
Answer
Completed Survey
Just a sample elaboration of what Steven and Chris has mentioned above.
There are gonna be multiple tables, if there are gonna be multiple surveys, and each survey has a different set of questions, and if same user can take multiple surveys.
Customer Table with CustID as the primary key
Questions Table with a Question ID as the primary key. If a question cannot belong to more than one survey (a N:1 relationship), then can also have Survey ID (of table Survey table mentioned in point 3) as one of the values in the table.
But if a Survey to Question relationship is N:M, then
(SurveryID, QuestionID) would become a composite key for the SurveyTable, else it would just have the SurveyID with the high level details of the survey like description.
UserSurvey table which would contain (USerID, SurveryID, QuestionID, AnswerGiven)
[Note: if same user can take the same survey again and again, either the old survey has to be updated or the repeat attempts have to stored as another rows with some serial number)