I have entity called Dimension. It has three attributes - ID, width and height.
ID is primary key. In the table, the dimension should be unique so there has to be only one record with given dimension (for example 40x30). What constraints I need to set?
Is uniqueConstraints={#UniqueConstraint(name="dimension", columns={"width", "height"})} correct?
From the documentation,
#UniqueConstraint annotation is used inside the #Table annotation on
the entity-class level. It allows to hint the SchemaTool to generate a
database unique constraint on the specified table columns. It only has
meaning in the SchemaTool schema generation context.
Required attributes:
name: Name of the Index
columns: Array of columns.
The anwser is then YES
/**
* #Entity
* #Table(name="xxx",uniqueConstraints={#UniqueConstraint(name="dimension", columns={"width", "height"})})
*/
class Dimension
should then do the job.
Related
New to feature tools, getting this error while creating entity
Unable to add relationship because child column 'order_id' in 'orders' is also its index
I suspect that featuretools expect one to many relationship, is there a way to specify one to one relationship?
Yes, Featuretools generally expects a one to many relationship between tables in an EntitySet, which is why the child column cannot be the index of its table.
There's not a way to override this in relationship creation, but you can take steps to use a different index column in the child dataframe, allowing order_id to be the child column of the relationship.
You could create a new index column in prejoin_foodorder by setting make_index=True and the index to be some column name that's not in the DataFrame when adding the table to the EntitySet. This will create a new integer column in the DataFrame that ranges from 0 to the length of the dataframe. That column will then be used as the DataFrame's index, leaving order_id to be used as the child column of a relationship.
es = EntitySet()
... add any other dataframes to the EntitySet ...
es.add_dataframe('prejoin_foodorder', index='new_index', make_index=True, ...)
es.add_relationship(parent_dataframe_name='orders',
parent_column_name='id',
child_dataframe_name='prejoin_foodorder',
child_column_name='order_id')
A relation in the relational model is what SQL represents with a table. We could say that a table is an attempt by SQL to represent a relation.
Getting back to a relation, which is what SQL attempts to represent with a table: a relation
has a heading and a body. The heading is a set of attributes (what SQL attempts to represent
with columns), each of a given type. An attribute is identified by name and type name. The
body is a set of tuples (what SQL attempts to represent with rows). Each tuple’s heading is the
heading of the relation. Each value of each tuple’s attribute is of its respective type.
What do we mean by the heading of a relation is a set of attributes, and the body is a set of tuples?
If we consider these two tables :
Employee : EmployeeId,FirstName,LastName,DepartmentId
Department : DepartmentId, DepartmentName, Description
If I want to select the employees and their departments, the query will be like following :
SELECT * FROM Employee E
LEFT Department D ON E.DepartmentId=D.DepartmentId
In this case what is the heading and the body corresponding to mathematic definition of relational ?
In the relational model
An attribute is a name paired with a data type.
A set of attributes with unique names is called a heading.
A tuple is a set of attribute values corresponding to a specific heading.
A relation is a unsorted, unique set of tuples.
A tuple can only be a part of a relation if their heading match exactly.
A set of tuples that all correspond to the same heading is called a body.
Therefor, a relation the combination of a specific heading and a body (which is a set of tuples that correspond to this heading).
In a relational database
A relation is implemented as a table.
(Note: The relational model describes the tuples in a relation as unique, but no RDBMS I know of enforces that rule unless a unique key (in the form of a primary key, unique constraint or unique index) is declared.
A Heading is the table's column definition.
A tuple is a row within a table.
An attribute value is the value of a specific column in a specific row.
To answer your question
In this case what is the heading and the body corresponding to mathematic definition of relational ?
Given the tables you've described in your question, and the query you're using to select from these table, the resultset of that query can not be considered as a relation, since it has a duplicate attribute in it's heading - the DepartmentId column exists in both source tables.
This is why the database will not let you create a view (or a cte) from this query - since a view or cte column names must be unique in order to provide a proper heading.
For more information, read Relation (database) over on Wikipedia.
I have this fact table
I want to create a calculated member like this : S = the sum of the "TOT_LIV" that have the "NUM_PROD" = 1
For example:
S should be equal to 50
How could I do it ?
Assuming you have a measure defined on this fact table named "TOT LIV", this measure has "Sum" defined as its aggregate method, and that NUM_PROD is a foreign key to a dimension named Prod having an attribute named Num Prod which I assume being based on the primary key of the dimension, and hence it would be 1 as well for the records that are references by the NUM_PROD primary key, you would use
([Measures].[TOT LIV], [Prod].[Num Prod].[1])
You see there is no 1:1 translation from SQL to MDX, a lot of things depend on cube setup, which predefines many behaviors that you have to repeat again and again in SQL queries (like the usage of sum).
In order to evaluate the load of our platform (django + postgresql) I would like to literally duplicate the amount of data in the system. Its a bit complicated to create mocks that could emulate the different kind of objects (since we have a very complex data model).
Is there a way to create a duplicate of the database, override primary keys and unique fields for unused ones an merge it with the original?
(I) Explaining the principle
In order to illustrate the principle in a clear way, this explanation assumes the following:
every table has a bigserial primary key column called "id"
No unique constraints on tables (except primary keys)
Foreign key constraints reference only primary keys of other tables
Apply following to your database schema:
Make sure there is no circular dependencies between tables in your schema. If there are, choose foreign key constraints that would breake such dependency and drop them (you will later recreate them, after you manually handle affected fields).
Sort tables in topological order and, in that order, for every table execute script from (3)
For every table <table_schema>.<table_name> from (2) execute:
/*
Creating a lookup table which contains ordered pairs (id_old, id_new).
For every existing row in table <table_schema>.<table_name>,
new row with id = new_id will be created and with all the other fields copied. Nextval of sequence <table_schema>.<table_name>_id_seq is fetched to reserve id for a new row.
*/
CREATE TABLE _l_<table_schema>_<table_name> AS
SELECT id as id_old, nextval('<table_schema>.<table_name>_id_seq') as id_new
FROM <table_schema>.<table_name>;
/*
This part is for actual copying of table data with preserving of referential integrity.
Table <table_schema>.<table_name> has the following fields:
id - primary key
column1, ..., columnN - fields in a table excluding the foreign keys; N>=0;
fk1, ..., fkM - foreign keys; M>=0;
_l_<table_schema_fki>_<table_name_fki> (1 <= i <= M) - lookup tables of parent tables. We use LEFT JOIN because foreign key field could be nullable in general case.
*/
INSERT INTO <table_schema>.<table_name> (id, column1, ... , columnN, fk1, ..., fkM)
SELECT tlookup.id_new, t.column1, ... , t.columnN, tablefk1.id_new, ..., tablefkM.id_new
FROM <table_schema>_<table_name> t
INNER JOIN _l_<table_schema>_<table_name> tlookup ON t.id = tlookup.id_old
LEFT JOIN _l_<table_schema_fk1>_<table_name_fk1> tablefk1 ON t.fk1 = tablefk1.id_old
...
LEFT JOIN _l_<table_schema_fkM>_<table_name_fkM> tablefkM ON t.fkM = tablefkM.id_old;
Drop all lookup tables.
(II) Describing my implementation
To check for circular dependencies, I queried the transitive closures (https://beagle.whoi.edu/redmine/projects/ibt/wiki/Transitive_closure_in_PostgreSQL)
I implemented topological sort function (ported from t-sql from some blog). It comes in handy for automations.
I made a code generator (implemented in plpgsql). It's a function which takes <table_schema> and <table_name> as input params and returns text (SQL) shown in (I.2) for that table. By concatenating results of the function for every table in topological order, I produced the copy script.
I made manual changes to the script to satisfy unique constraints and other nuances, which boilerplate script doesn't cover.
Done. Script ready for execution in one transaction.
When I get the chance, I will "anonimize" my code a little bit and put it on github and put a link here.
I want to define extra properties for the columns in the tables of my MYSQL database.
For example I want to define the measurement units of the columns of my database.
To do that I currently plan to create this table :
COLUMN_UNIT
id
{table_name, column_name} unique constraint
unit_id
(I am not using a composite PK because my framework required an auto incremented ID field)
The other tables that I could have are :
UNIT
id
unit_name
WEATHER_DATA
temperature
wind_speed
...
SENSOR_DATA
intensity
frequency
...
Is using the column name and the table name the best way to refer to other column?
Thanks!
UPDATE :
In my case all the records in a column will have the same property value. It is a column wise property. So for the temperature, all the values will be in degree C for example.
you need to use multiple foreign keys to the UNIT table.. for example, your WEATHER_DATA table could be
WEATHER_DATA
temperature
temperature_unit_id (FK to UNIT)
wind_speed
wind_unit_id (FK to UNIT)
i don't know if your framework allows multiple foreign keys on the same table... If it doesn't, i guess that you could create another table containing the name of the table, the nane of the column and the unit_id.. but that would be =S ugly
Hope it helps
EDIT:
you could use a meta table that are just tables that store extra information of your table.. mysql uses his own metatables to store the number of rows, the column types, etc. Some frameworks use their own meta tables (like Django).. But you could create your own meta tables,they are just like any other table, in your case it could be something like
WEATHER_META
temperature_unit_id FK
wind_unit_id FK
and the WEATHER table would be
WEATHER_DATA
id
temperature
wind_speed
...
Or if you want to, you could create a single Meta table for all your tables. Something like
META_TABLES
table_name
column_name
unit_id