I'm currently building a small database on MS Access for upgrades (45) on several machines (30) on a factory. The info is on an excel spreadsheet where rows are the upgrades and columns the machine. The excel file shows how for each machine if a certain upgrade is already installed/to be installed/in dev/etc.
I currently have a table for each upgrade details and another table with every machine and its personal info.
To replicate the excel associations I intend on making a junction table.
Should I make it with the upgrades as a field (1 col) and the machine as another. That would give 3 columns and 30*45 rows.
Or should I imitate the excel and put the upgrades as a field and each machine as an individual field, the values being the state of the upgrade.
Thanks in advance
A junction table is typically used to build a many-to-many relationship. From what you describe, it seems to be the case that you have. The fields of the junction Table must include the Key field(s) of the two Tables between which you want to establish a many-to-many relationship. In your case, it seems that the junction table should have the key field(s) of table "machines" and the key field(s) of table "upgrades". You then build a one-to-many relationship with referential integrity from the table "machines", over the key fields, to the corresponding fields in the junction table. You do the same from the key field(s) of the table "upgrades" to the corresponding fields of the junction table. Then you populate the junction table with the corresponding data. It is quite frequent to include additional fields inthe junction table to provide useful information, like having a date field to record on what date each upgrade was done for each specific machine, or a comments fields, or the person that did the upgrade.
If you want to see a concrete example, you can take a look to the juntion Table "T_Umbrellas_in_Capitals" from the database of examples that you can download from LightningGuide.net. This junction table supports a many-to-many relationship between the tables "T_Capital_cities" and "T_Umbrella_models".
Related
I have a database design in which I have aprox. 5 entities that can be filtered. Currently these tables all have their own filter table, e.g. the product table has a productfilter table and the customer has a customerfilter table.
I have done some research since performance (as in speed to query the db) is the most important quality attribute, I am wondering whether having a single filter table and connecting the entities that rely on it with junction tables is a better option?
Important side note the filters would only ever be joined from the Customer or Product entities when using the junction tables.
Edit:
1: Without junction tables
2: With junction tables
I have such schema:
The essence of this scheme is in organization of the entry point for all products of some company, that gives some flexibility.
How it works:
We create a list of tables in the table "tables" (where name is the name of the table in database, pk_name is the name of the primary key of this table)
We create a list of products in "products" (where table_id is the table identifier in "tables", pk_value is the value of the primary key)
Also, we create tables like "some_product", "another_product", etc. They contain different fields for a specific product
The questions are:
How such schemes are called? For example, EAV is also designed for
database flexibility, but in EAV columns are stored as records in
the database.
Therefore, I can not understand is it advisable to compare this scheme with EAV or not?
What analogies of this schema are there, to understand what is better to use?
What are disadvantages of this schema?
I'm novice in DB, so I hope that my questions are not stupid.
Thank you!
In the example you have shown both some_product and another_product tables have the same attributes and types. It would be better to have one product table in that case. If different attributes apply to different types of product in different tables then that is an example of subtyping.
Attributes that are common to all products would go in the common products table (the supertype table). I would expect to see a product type attribute in that table to differentiate the various types of product.
The tables table is unnecessary. All DBMSs provide access to the metadata about tables and primary keys so there is no reason to capture that in your own table.
I have Transaction table that contain transactions related cashiers transactions. Transactions might be two sales and refund and are defined in TransType table. Possible in future we will have more. Trying to show this in Visio 2016, but not sure I do it correctly.
How to define set of available record values in TranType and define relation to Transactios table. What type relation it would be?
I would recommend creating a TransTypeId in your TransType table.
Then, in the Transactions table, create a column that serves as a foreign key, linking the two tables. TransTypeFk in your Transactions tables should then be an integer with a foreign key constraint to TransTypeId.
As a note, your relationship path between the two entities should always connect two specific columns, not a column and an entity.
The relationship would be one TransType to many Transactions.
You can define the set of available records by adding rows to that database. For Visio, using a note or text box would likely work fine.
I've read a lot of tips and tutorials about normalization but I still find it hard to understand how and when we need normalization. So right now I need to know if this database design for an electricity monitoring system needs to be normalized or not.
So far I have one table with fields:
monitor_id
appliance_name
brand
ampere
uptime
power_kWh
price_kWh
status (ON/OFF)
This monitoring system monitors multiple appliances (TV, Fridge, washing machine) separately.
So does it need to be normalized further? If so, how?
Honestly, you can get away without normalizing every database. Normalization is good if the database is going to be a project that affects many people or if there are performance issues and the database does OLTP. Database normalization in many ways boils down to having larger numbers of tables themselves with fewer columns. Denormalization involves having fewer tables with larger numbers of columns.
I've never seen a real database with only one table, but that's ok. Some people denormalize their database for reporting purposes. So it isn't always necessary to normalize a database.
How do you normalize it? You need to have a primary key (on a column that is unique or a combination of two or more columns that are unique in their combined form). You would need to create another table and have a foreign key relationship. A foreign key relationship is a pair of columns that exist in two or more tables. These columns need to share the same data type. These act as a map from one table to another. The tables are usually separated by real-world purpose.
For example, you could have a table with status, uptime and monitor_id. This would have a foreign key relationship to the monitor_id between the two tables. Your original table could then drop the uptime and status columns. You could have a third table with Brands, Models and the things that all models have in common (e.g., power_kWh, ampere, etc.). There could be a foreign key relationship to the first table based on model. Then the brand column could be eliminated (via the DDL command DROP) from the first table as this third table will have it relating from the model name.
To create new tables, you'll need to invoke a DDL command CREATE TABLE newTable with a foreign key on the column that will in effect be shared by the new table and the original table. With foreign key constraints, the new tables will share a column. The tables will have less information in them (fewer columns) when they are highly normalized. But there will be more tables to accommodate and store all the data. This way you can update one table and not put a lock on all the other columns in a denormalized database with one big table.
Once new tables have the data in the column or columns from the original table, you can drop those columns from the original table (except for the foreign key column). To drop columns, you need to invoke DDL commands (ALTER TABLE originalTable, drop brand).
In many ways, performance will be improved if you try to do many reads and writes (commit many transactions) on a database table in a normalized database. If you use the table as a report, and want to present all the data as it is in the table normally, normalized the database will hurt the peformance.
By the way, normalizing the database can prevent redundant data. This can make the database consume less storage space and use less memory.
It is nice to have our database normalize.It helps us to have a efficient data because we can prevent redundancy here and also saves memory usages. On normalizing tables we need to have a primary key in each table and use this to connect to another table and when the primary key (unique in each table) is on another table it is called the foreign key (use to connect to another table).
Sample you already have this table :
Table name : appliances_tbl
-inside here you have
-appliance_id : as the primary key
-appliance_name
-brand
-model
and so on about this appliances...
Next you have another table :
Table name : appliance_info_tbl (anything for a table name and must be related to its fields)
-appliance_info_id : primary key
-appliance_price
-appliance_uptime
-appliance_description
-appliance_id : foreign key (so you can get the name of the appliance by using only its id)
and so on....
You can add more table like that but just make sure that you have a primary key in each table. You can also put the cardinality to make your normalizing more understandable.
I am looking for ideas to populate a fact table in a data mart. Lets say i have the following dimensions
Physician
Patient
date
geo_location
patient_demography
test
I have used two ETL tools to populate the dimension tables- Pentaho and Oracle Warehouse Builder. The date, patient demography and geo locations do not pull data from the operational store. All dimension tables have their own NEW surrogate key.
I now want to populate the fact table with the details of a visit by a patient.When a patient visits a physician on a particular date, he orders a test. This is the info in the fact table. There are other measures too that I am omitting for simplicity.
I can create a single join with all the required columns in the fact table from the source system. But, i need to store the keys from the dimension tables for Patient, Physician, test etc.. What is the best way to achieve this?
Can ETL tools help in this?
Thank You
Krishna
Each dimension table should have a BusinessKey that uniquely identifies the object (person, date, location) that a table row describes. During loading of the fact table, you have to lookup the PrimaryKey from the dimension table, based on the BusinessKey. You can choose to lookup the dimension table directly, or create a key-lookup table for each dimension just before loading the fact table.
Pentaho Kettle has the "Database Value Lookup" (transformation step) for the purpose. You may also want to look at the "Delivering Fact Tables" section of Kimball's Data Warehouse ETL Toolkit.