I am trying to track the evolution of the number of employees in over 90 companies in a specific region with Linked-In. Right now, I have someone who goes on each company's Linked-In profile every month and collect the data (I know..).
Is there a more efficient (and legal) way to do that? (Linked-In APIs, etc.)
Could I also extract the list of employees of each company automatically? (to track who is hired and leaving each company)
Thank you,
Mayol
Related
I do descriptive analytics and reporting at a company that sells a wide range of products. We record sales transactions and everytime an item is sold, the following is recorded:
Customer ID (each customer has a unique ID)
Product ID (each product has a unique ID)
Sale date
(Other fields are recorded too - location of purchase, quantity, payment type, etc.)
We sell a few big ticket items, and what I'm wondering is if it's possible to predict whether a customer will buy one of the big ticket items based on their purchase history, using transactional data as described above. We have about 2 million rows of sales data spanning seven years, and in that time maybe 14,000 big ticket items have been sold to 5,000 out of 50,000 customers.
I use SQL Server 2008 R2 which has the data mining feature. I did some brief reading on it but can't figure out what model would be best, or if it's something that's even doable. Can someone point me in the right direction to get started?
Not sure if the SQL server data mining feature is useful. I took a look at the one for SQL 2012 and decided it wasn't.
As for your prediction, this would be a supervised learning problem (just pick any simple algorithm), where each customer is a row and your features would be the different products. Your positive labels then would then be the rows of customers that had bought big ticket items.
what you are looking for is called sequential pattern mining and the specific technique that you are looking for is called discrete event prediction. However with that being said, I don't think you will be able to do what you want to do with an out of the box solution on sql server.
I have been given the following scenario :
HyperAV is a retailer of home cinema equipment. They sell a variety of products including televisions, speakers, amplifiers, Blu-ray/DVD players and cables. The company has its head office in Stockport and 5 retail branches around the UK (in London, York, Cardiff, Manchester and Newcastle) and a large warehouse in Birmingham.
Due to the specialised nature of the products most sales are made in the shops which also have demonstration facilities allowing staff to show off the products to customers before they buy. However, the shops can also take orders over the telephone. The company deals with a number of suppliers who deliver items to both the shops and the warehouse. Limited space is available in the shops, so large numbers of items are stored at the warehouse and sent to the shops when their stock runs low.
The company’s buyer and stock controller are based in Stockport and work together to ensure that each branch has an adequate stock level of fast-selling items. If a shop takes an order for a product that it does not hold in stock, payment is taken and the item is sent to the shop from the warehouse. If the warehouse does not have a product in stock, it is ordered from the supplier by the buyer.
From this scenario I have been asked to draw a use case diagram.
I have received feedback but only to an extent where I have been told it is slightly incorrect. I would like to know if anyone can see what is wrong with it or how i can improve it in anyway?
I will not go and analyze what is right/wrong with your business case, but here are a few remarks:
Do not use Generalization with UCs. Each UC shall be a unique added value the system under consideration (SUC) delivers to the actor. If you have Generalization this means your UC is not unique. E.g. Deliver product: these are two absolutely separate UCs. They use a delivery service. But that's a UC for another SUC (namely the delivery service).
Avoid the use of <<include>>/<<extend>> as they indicate the use of functional analysis. UCs are about synthesis which is the opposite of that.
Use verb-substantive to name your UC. Order for example is not a UC.
Think about the "use" in UC. What is the added value it returns to its actor? If that is not of a real use, it's not UC. Process payment is an administrative task, not a UC. So what is the use behind this?
Having a few issues with my database design. I have designed my system like the following image
As you can see it is a pretty basic system to a point. A user can create a supplier by adding supplier details. A user can then add a product and link it to a supplier. Thats the pretty straight forward bit (I hope!). Now I will attach my database design which should hopefully cover what I have mentioned.
So a supplier can have one contact (person within the suppliers company the user of my system will contact) and a supplier can have one to many products.
He is the part I can't figure out. Twice a week, the user of my system will receive stock from all their suppliers. When they receive this stock, they should go into the update stock screen within the application and input the amount of stock they have received for a certain product. I have added a products_stock table which should hopefully put me on my way to cover this aspect (I think it is missing a lot though).
The last screen however is a display of predicted stock. Lets say for instance on the day my products are delivered, I receive 10 units for Product One. I will then manually count the number of units I have left from the last order for Product One (say 2) and update the stock count for Product One to 12.
This means, that really, I only needed 8 units between the two deliveries for product one. The predicted stock screen is supposed to show the predicted stock levels I should place an order for, for a particular product, over a specified time period. So if 8 units was the average stock sold for product one per week, if I wanted to see how many units I should order for product one for a month, it should display about 32 units.
This is not supposed to be a complex system, it should have this manual aspect to it. I have designed the database up until a point, I was hoping I could get some suggestions regarding the products_stock table and how I can handle stock predictions for a specific period of time (if I maybe need additional tables).
Any advice appreciated.
Thanks
Inventory is more like a view and not a table. Inventory is really a series of movements of goods between locations, as well as periodic counts / adjustments.
Inventory is complex. You should play with some inventory software and read some data modeling books.
Use the concepts of Locations (real and virtual) and Movements (a movement should be its own entity).
Item smashes? Move it from its inventory location to the "damaged" location
Item went missing? Move it from inventory to the "ether" location
Found a random Item? Move it from "ether" to inventory
Sold an Item? Move it from inventory to "sold"
Bought an Item? Move it from purchased to inventory
Some other things to keep in mind:
You could sell something, and it's returned, and you put it back in
inventory
You could buy something, but it ain't right, so you send it
back to the seller
You could sell something that you don't own (on
consignment, or not in inventory yet)
You might have something in
inventory that is not currently for sale.
I won't get into the accounting aspects of inventory :)
One possible approach:
Have a separate "stock item" record for each unit received. When it is sold, record the date of sale in this record.
Then if you want to know how many items were sold in a given time range, just count the records with sold dates in that range, like select count(*) from stock_item where product_id=#product and sold_date between #from and #thru. If you need to keep track of items lost to spoilage, theft, whatever, then you might have a status flag of some kind that says whether it's in stock, sold, destroyed, whatever, and also the date of that status.
If the number of units that pass through is large and there's no other reason to keep individual stock records, you could just have "daily sales" records instead, with a date and number sold that day. Same idea.
I'm really stuck on the best way to implement this database.
Here is my problem: The database is to store information on wedding photography clients.
A user can sign up to my site, enter the details of their wedding and get their own "wedding profile page". They can do this without having to have us shoot their wedding.
At any point the user can book a meetup, wedding, or engagement shoot. The website will check if we are available. (weddings take preference over meetups so a client that wants to book a wedding on a day we have a meetup, the meetup will be flagged for a reschedule)
We must also be able to book days off. On these days a wedding/meetup/engagement shoot can not be booked.
engagement shoots cost and upfront fee. With weddings, a deposit is due within 14 days or the date is freed up again. Meetups are free.
I am so stuck with how to implement this system. I just keep going round in circles, the best way I can think is to have a "dates" table, that links all the other tables but I'm sure this is not the most efficient way.
I think what is putting me off is the fact that there can be multiple weddings on the same day (for people who just want a wedding profile), but only one BOOKED wedding per day.
So have I got this completely wrong? or do I store all appointments in one table and use a "type of appointment" table.
SO SO Stuck, I hope you can help me!
P.S. I have missed most fields out to make it simpler to understand.
Keep it simple to begin with. You've identified many of the nouns that should correspond to entities:
USERS
WEDDINGS
ENGAGEMENT_SHOOTS
MEETUPS
UNAVAILABLE
DATES
PAYMENTS
I'd suggest that WEDDINGS, ENGAGEMENT_SHOOTS, MEETUPS and UNAVAILABLE are all type of bookings. You could have just:
USERS
BOOKINGS - this has a date and perhaps a status
BOOKING_TYPE (wedding, meetup, engagement_shoots, unavailable)
PAYMENTS
You may wish to package up all on the things a use has bought relating to a single wedding into a TRANSACTION entity etc which will allow a single payment to be mapped to multiple bookings. When one of your staff isn't available they could have a booking of type holiday etc.
There may be 2 types of USERS - your photography staff who are assigned to a booking and your customer.
Based on the status of the booking, eg. CONFIRMED, PENDING, COMPLETED and the date your business logic could send out payment demands, followups etc.
Create a simple model and start adding data you will soon see the gaps and issues if any. You should have test cases up front to ensure that the data model supports all the scenarios for your application, best to do this with a set of use cases.
Each reservation contains names of the guests & a company name.
Now, the guests may/may not belong in a company. (a booking may have a company as null)
Currently, I have:
Booking_table (booking_id, guest_id, company_id)
Guest_table (guest_id, guest_name)
Company_table (company_id, company_name)
Guest_booking_history (guest_id, booking_id)
Company_booking_history (company_id, booking_id)
Am I doing this right? Any suggestions in designing the database?
An alternative would be:
Booking_table (booking_id, guest_names, company_id)
Company_table (company_id, company_name)
It's mostly good, but I'd consider adding the company to the guest, and maybe remove the company from the booking table. Something like:
Booking_table (booking_id, guest_id)
Guest_table (guest_id, guest_name, company_id)
Other than that, I think your database is missing a lot of important data - dates, customer info, etc, but that's a whole other issue fully dependent on exactly what you want to achieve with the database and software.
Seems like it would be usefull to have the booking dates, and booking needs likely needs to be linked to a table of rooms.
It all depends on what data you want to keep and track ;)
Other then that, if this is homework mark it as that.