Decision Trees: Decision tree output is very easy to understand even for people from non-analytical background. It does not require any statistical knowledge to read and interpret them. Fastest way to identify most significant variables and relation between two or more variables. Decision Trees are excellent tools for helping you to choose between several courses of action. Most popular decision trees are CART, CHAID, and C4.5 etc.
In general, decision trees can be used in real-world applications such as:
· Investment decisions
· Banks loan defaulters
· Build vs Buy decisions
· Company mergers decisions
· Sales lead qualifications
Logistic Regression: Logistic regression is a powerful statistical way of modeling a binomial outcome with one or more explanatory variables. It measures the relationship between the categorical dependent variable and one or more independent variables by estimating probabilities using a logistic function, which is the cumulative logistic distribution.
In general, regressions can be used in real-world applications such as:
· Predicting the Customer Churn
· Measuring the effectiveness of marketing campaigns
Support Vector Machines: Support Vector Machine (SVM) is a supervised machine learning technique that is widely used in pattern recognition and classification problems - when your data has exactly two classes.
In general, SVM can be used in real-world applications such as:
· detecting persons with common diseases such as diabetes
· hand-written character recognition
· text categorization – news articles by topics
· stock market price prediction
Naive Bayes: It is a classification technique based on Bayes’ theorem and very easy to build and particularly useful for very large data sets. Along with simplicity, Naive Bayes is known to outperform even highly sophisticated classification methods. Naive Bayes is also a good choice when CPU and memory resources are a limiting factor
In general, Naive Bayes can be used in real-world applications such as:
· Sentiment analysis and text classification
· Recommendation systems like Netflix, Amazon
· To mark an email as spam or not spam
· Facebook like face recognition
Apriori: This algorithm generates association rules from a given data set. Association rule implies that if an item A occurs, then item B also occurs with a certain probability.
In general, Apriori can be used in real-world applications such as:
· Market basket analysis like amazon - products purchased together
· Auto complete functionality like Google to provide words which come together
· Identify Drugs and their effects on patients
Random Forest: is an ensemble of decision trees. It can solve both regression and classification problems with large data sets. It also helps identify most significant variables from thousands of input variables.
In general, Random Forest can be used in real-world applications such as:
· Predict patients for high risks
· Predict parts failures in manufacturing
· Predict loan defaulters
The most powerful form of machine learning being used today, is called “Deep Learning”.
In today’s Digital Transformation age, most businesses will tap into machine learning algorithms for their operational and customer-facing functions.
Source: http://www.iotcentral.io/blog/want-to-know-how-to-choose-machine-learning-algorithm
Showing posts with label Modeling. Show all posts
Showing posts with label Modeling. Show all posts
Friday, December 23, 2016
A simple overview - random forests, decision trees, regression, oh my!
Looking for an easy summary overview for decision trees, regressions, support vectors, and bayes? Well, we found on at iocentral.io. You can find it at: Want to know how to choose Machine Learning algorithm? We've replicated the core parts below:
Monday, August 8, 2016
Visio Shapes (vssx) on TechNet
You can find a long list of Visio shapes, symbols and icons on TechNet for Visio 2016/2013. It's called the Integration Stencils Pack and you can find it here: Microsoft Integration Stencils Pack for Visio 2016/2013.
Monday, April 18, 2016
What is the proper key for the clustered index?
In data modeling a table one of the more difficult questions is: should my primary key (PK) have a clustered or non-clustered index? One of the best answers I've seen for this question has been posted on StackExchange. The answer starts by rephrasing the question:
The question is not 'when should the PK be NC', but instead you should ask 'what is the proper key for the clustered index'? And the answer really depends on how do you query the data.
The clustered index has an advantage over all other indexes: since it always includes all columns, is always covering. Therefore queries that can leverage the clustered index certainly do not need to use lookups to satisfy some of the projected columns and/or predicates.
Another piece of the puzzle is how can an index be used? There are three typical patterns:
So if you analyze your expected load (the queries) and discover that a large number of queries would use a particular index because they use a certain pattern of access that benefits from an index, it makes sense to propose that index as the clustered index.
Yet another factor is that the clustered index key is the lookup key used by all non-clustered indices and therefore a wide clustered index key creates a ripple effect and widens all the non-clustered indices and wide indices mean more pages, more I/O, more memory, less goodness.
A good clustered index is stable, it does not change during the lifetime of the entity, because a change in the clustered index key values means the row has to be deleted and inserted back.
And a good clustered index grows in order not randomly (each newly inserted key value is larger than the preceding value) as to avoid page splits and fragmentation (without messing around with FILLFACTORs).
So now that we know what a good clustered index key is, does the primary key (which is a data modelling logical property) match the requirements? If yes, then the PK should be clustered. If no, then the PK should be non-clustered.
To give an example, consider a sales facts table. Each entry has an ID that is the primary key. But the vast majority of queries ask for data between a date and another date, therefore the best clustered index key would be the sales date, not the ID. Another example of having a different clustered index from the primary key is a very low selectivity key, like a 'category', or a 'state', a key with only very few distinct values. Having a clustered index key with this low selectivity key as the leftmost key, e.g. (state, id), often makes sense because of ranges scans that look for all entries in a particular 'state'.
One last note about the possibility of a non-clustered primary key over a heap (i.e. there is no clustered index at all). This may be a valid scenario, the typical reason is when bulk insert performance is critical, since heaps have significantly better bulk insert throughput when compared to clustered indices.
this answer edited Dec 1 '12 at 4:31 Paul White
answered Nov 10 '11 at 22:39 Remus Rusanu
originally posted at:
http://dba.stackexchange.com/questions/7741/when-should-a-primary-key-be-declared-non-clustered
You can read the full listing on Stackexchange
here: When should a primary key be declared non-clustered?
What is the proper key for the clustered index?
Here is cited copy of response. With a link below to the full listing.The question is not 'when should the PK be NC', but instead you should ask 'what is the proper key for the clustered index'? And the answer really depends on how do you query the data.
The clustered index has an advantage over all other indexes: since it always includes all columns, is always covering. Therefore queries that can leverage the clustered index certainly do not need to use lookups to satisfy some of the projected columns and/or predicates.
Another piece of the puzzle is how can an index be used? There are three typical patterns:
- probes, when a single key value is seek-ed in the index
- range scans, when a range of key values is retrieved
- order by requirements, when an index can satisfy an order by w/o requiring a stop-and-go sort
So if you analyze your expected load (the queries) and discover that a large number of queries would use a particular index because they use a certain pattern of access that benefits from an index, it makes sense to propose that index as the clustered index.
Yet another factor is that the clustered index key is the lookup key used by all non-clustered indices and therefore a wide clustered index key creates a ripple effect and widens all the non-clustered indices and wide indices mean more pages, more I/O, more memory, less goodness.
A good clustered index is stable, it does not change during the lifetime of the entity, because a change in the clustered index key values means the row has to be deleted and inserted back.
And a good clustered index grows in order not randomly (each newly inserted key value is larger than the preceding value) as to avoid page splits and fragmentation (without messing around with FILLFACTORs).
So now that we know what a good clustered index key is, does the primary key (which is a data modelling logical property) match the requirements? If yes, then the PK should be clustered. If no, then the PK should be non-clustered.
To give an example, consider a sales facts table. Each entry has an ID that is the primary key. But the vast majority of queries ask for data between a date and another date, therefore the best clustered index key would be the sales date, not the ID. Another example of having a different clustered index from the primary key is a very low selectivity key, like a 'category', or a 'state', a key with only very few distinct values. Having a clustered index key with this low selectivity key as the leftmost key, e.g. (state, id), often makes sense because of ranges scans that look for all entries in a particular 'state'.
One last note about the possibility of a non-clustered primary key over a heap (i.e. there is no clustered index at all). This may be a valid scenario, the typical reason is when bulk insert performance is critical, since heaps have significantly better bulk insert throughput when compared to clustered indices.
this answer edited Dec 1 '12 at 4:31 Paul White
answered Nov 10 '11 at 22:39 Remus Rusanu
originally posted at:
http://dba.stackexchange.com/questions/7741/when-should-a-primary-key-be-declared-non-clustered
You can read the full listing on Stackexchange
here: When should a primary key be declared non-clustered?
Subscribe to:
Posts (Atom)