I am building up data model and I was trying a data model for Rideshare
Here is what I have so far
Trip Fare Fact table
Timestamp
TripId
DriverId
RiderId
TripStatus(Cancelled_by_driver, Cancelled_by_rider, matched, completed)
SrcLocation
DstLocation
TripCost
Dimension tables:
Driver
DriverId
Name.
Address.
PaymentId
CarMakeAndModel
Rating
Rider
RiderId.
Name.
Address.
PaymentId.
I can create dimension table for Timestamp, address, PaymentId. What other things I should try.
Let us say if I want to calculate number of trips taken by Driver/Rider per day over last x days. How does the data get rolled up for this.
Related
got a python sqlite3 spider crawling through a website and essentially got an address, and the dates that it was sold for along with the corresponding prices it was sold for. The first database is for address, postcode, number of bedrooms and second is points in time it was sold I am thinking of arranging the second database that has prices like so :
(Unique_id, date_1, sale_price_1, date_2, sale_price_2...etc..etc)
but this does not seem very efficient, for example, I may put down five date and sale columns but the crawler may come across a house sold seven times... is there a more efficient way to organise the second database of sold prices?
thank you in advance
I would create two tables: one for houses, and one for transactions and link them via a foreign key.
Each house will only have one row in the houses table, but may have any number of rows in the transactions table.
The transactions table will have a foreign key to the house that was sold, along with columns about the sale, such as date and sale price.
I'm doing my own project and have something to store in mysql database.
After thinking what should be a best solution DO NOT repeat same value's in DataBase again I didn't find an answer.
So let's example,
Table Cars with rows Cars_ID and Cars_VALUE
-=JoinTable between Cars and Cars_CreationDate=-
Table Cars_CreationDate with rows Cars_CreationDate_ID and Cars_CreationDate_VALUE
-=JoinTable between Cars_CreationDate and Cars_Description=-
Table Cars_Description with rows Cars_Description_ID and Cars_Description_VALUE
In hibernate entities I would have relationships like this:
Between Entity Cars_CreationDate and Cars #ManyToMany, owner of relationships is Cars_CreationDate. Because many Cars can be made in one date and one date can have many cars.
Between Entity Cars_Description and Cars #ManyToOne, owner of relationships is Cars entity, entity Cars_Description belongs to Cars. Entity Cars_Description everytime extracts from database with Cars. fetchType=EAGER
Now let's see if we have in DataBase some Cars made already and I want to add new date to this cars I would say:
Cars cars = (Cars)session.get(Cars.class, int idindatabase); // If we do this for a couple times more for different Cars we will have THE SAME Cars_Description_VALUE corresponds to different Cars so it would looks like this
2013-07-03 to CarOne
2013-07-03 to CarTwo
2013-07-03 to CarTree
and etc. So I don't need this dates repeat every time.
How do not let this problem to be??? Thank you
I don't see much value in using a separate entity/table to store a single value to avoid having to write them out - either a car has a date or a car has a reference to a date. I'd put the date in Car and be done with it. But in theory, what you want is a foreign key in Car to reference your Date. Each car will have a date ID that is used to find the date row/entity. Your date objects then can have a 1:M relationship back, so they can have a collection of cars.
in CarEntity:
#ManyToOne
#JoinColumn(name="CREATIONDATE_ID"
DateEntity creationDate;
In DateEntity:
#OneToMany(mappedby="creationDate")
Collection<CarEntity> cars;
I'm building a database that contains for each customer's purchase
Product Name
Product Manufacturer
Store
Date
Buyer's name
Buyer company
Some data such as product name, manufacturer, shop, buyer's name and the buyer's company back on themselves at the time.
Is it better to build them in separate tables and in the primary table to keep their indexes?
On the one hand it saves space on the server
On the other hand it overloads the server and requires more work
I would keep buyer information and product information in separate tables. There is no reason to store this information more then once.
In addition you could use a (relation like) table with buyer id, serialized array of product id's and date of the purchase.
buyer_id | {"prod1_id","prod2_id",...} | date
This way you get a table with all purchases that you can get whenever you want. This will increase the calls to the database but save on the storage.
Hope it makes sense to you.
I'm new to creating cubes, so please be patient.
Here's an example of my data
I have multiple companies, each company has multiple stores.
Sales are each linked to a particular company, with a particular store on a particular date.
ex:5 sales took place for Company A, Store 1, on 5/19/2011
Returns are linked to a particular company on a particular date.
ex: 3 returns took place for Company A on 3/11/2012
Sometimes my users want to see a list of stores, the date, and how many returns took place, and how many sales.
Sometimes they want to see a list of companies, the specific stores, and the number of sales.
I have a table that stores
COMPANY - DATE - STORE- SALES - RETURNS
I end up having the value for returns repeated for each store under a particular COMPANY - DATE pair.
so if I'm writing a query, and I want to find out returns, I just do a
select distinct company, date, returns from mytable
but I am not sure how to this into a cube (using SS BI and Visual Studio).
(I've only made a couple of cubes so far)
Thanks! (also, feel free to point me at appropriate references)
It sounds like Company is an attribute of the Store and should be in the Store dimension rather than the fact table. There may have to be a transformation on returns to convert the Company to a store.
Am I missing anything?
I need an elegant way to implement credit-based purchases for an online store with a small variety of products which can be purchased using virtual credit or real currency. Alternatively, products could only be priced in credits.
Previous work
I have implemented credit-based purchasing before using different product types (eg. Credit, Voucher or Music) with post-order processing to assign purchased credit to users in the form of real currency, which could subsequently be used to discount future orders' charge totals.
This worked fairly well as a makeshift solution, but did not succeed in disconnecting the virtual currency from the real currency, which is what I'd like to do, since spending credits is psychologically easier for customers than spending real currency.
Design
I need guidance on designing the database correctly with support for the simultaneous bulk purchase of credits at a discount along with real currency products. Alternatively, should all products be priced in credits and only credit have a real currency value?
Existing Database Design
Partial Products table:
ProductId
Title
Type
UnitPrice
SalePrice
Partial Orders table:
OrderId
UserId (related to Users table, not shown)
Status
Value
Total
Partial OrderItems table (similar to CartItems table):
OrderItemId
OrderId (related to Orders table)
ProductId (related to Products table)
Quantity
UnitPrice
SalePrice
Prospective UserCredits table:
CreditId
UserId (related to Users table, not shown)
Value (+/- value. Summed over time to determine saldo.)
Date
I'm using ASP.NET MVC and LINQ-to-SQL on a SQL Server database.
You don't pay your suppliers in Credits, so from an internal accounting perspective it would be better to hold only hard cash values (USD, UKP, whatever) against your products.
When displaying to your site's users you need a currency conversion table which translates hard prices into vouchers. Separating the data model from the front end display is a key design strategy. Whether you decide to show both real cash price and virtual credit price or just the credit valuation should have no bearing on how the data is stored in the database.
Talk to your accounting/finance people. Credit, once given, is as real as any money in double accounting, true you are not paying your suppliers in credits, but you are promising to deliver goods for credits that you will have to pay in hard cash. It should all balance at all times, and to see your complete financial position you should be able to get these credits in your balance sheet.
Try to model accounts and transactions, as well, right from the start - it will be easier to connect to finance/accounting software later and it is always good if you can run reports on both sides for purposes of reconciliation.