This is relational model for a OOP database, which of this is better?:
Note: -> this operand is used to define a foreign key like (field->table(reference))
First
**
attribute
(id:auto, attribute_name)
type
(id:auto, type_name)
type_attribute
(id:auto, type_code->type(id), attribute_id->attribute(id), default_value)
object
(id:auto, name, object_type->type(id))
object_property
(id:auto, object_id->object(id), attribute_id->attribute(id), my_value)
**
Second
attribute (id:auto, attribute_name)
type (id:auto, type_name)
type_attribute (id:auto, type_code->type(id),
attribute_code->attribute(id), default_value)
object (id:auto, name, object_type->type(id))
object_property (id:auto, (object_id,
object_type)->object(id,object_type), (object_type,
attribute_id)->type_attribute(id, attribute_id), my_value)
Really the difference is clearly visible at the object_property table.
In the first model you can define a property using the code and the attribute code, the problem here is that you can define elements that the type doesn't define the attribute for the type of the object. However, this model is most easy to use because for define an object_property you only need two codes like:
INSERT INTO object_property(object_code, attribute_code, my_value)
VALUES (3,4,'myvalue')
In the second model you can define a property using more consistent data using the object_code, object_type and the attribute_code. However you need to use three codes and additional query like this:
INSERT INTO object_property(object_code, object_type, attribute_code)
VALUES (3, (select object_type from object where code = 3), 4, 'my_value')
Which better?
Did you mean to say "relational model"? There is only one relational model:
we've never changed the axioms for the relational model. We have made
a number of changes over the years to the model itself—for example,
we've added relational comparisons—but the axioms (which are basically
those of classical predicate logic) have remained unchanged ever since
Codd's first papers. Moreover, what changes have occurred have all
been, in my view, evolutionary, not revolutionary, in nature. Thus, I
really do claim there's only one relational model, even though it has
evolved over time and will presumably continue to do so.
SQL and Relational Theory: How to Write Accurate SQL Code By C. J. Date
Related
Example: What is the difference between :
List<UserCompany> findByCompany_IdAndCompany_IsActivated(params)
and
List<UserCompany> findByCompanyIdAndCompanyIsActivated(params)
There is no difference if your model is unambiguous with respect to field names.
List<UserCompany> findByCompanyIdAndCompanyIsActivated(params) -
this first thinks that companyId and companyIsActivated are properties within UserCompany and tries to find them if fails
it then thinks that UserCompany has a field Company - which is another class and Company has field - Id and IsActivated and tries to find them
Where as the below thing
List<UserCompany> findByCompany_IdAndCompany_IsActivated(params)
assumes directly that UserCompany has a field Company - which is another class and Company has field - Id and IsActivated and tries to find them
From the spring documentation
Property expressions :---
Property expressions can refer only to a direct
property of the managed entity, as shown in the preceding example. At
query creation time you already make sure that the parsed property is
a property of the managed domain class. However, you can also define
constraints by traversing nested properties. Assume Persons have
Addresses with ZipCodes. In that case a method name of
List findByAddressZipCode(ZipCode zipCode); creates the
property traversal x.address.zipCode. The resolution algorithm starts
with interpreting the entire part (AddressZipCode) as the property and
checks the domain class for a property with that name (uncapitalized).
If the algorithm succeeds it uses that property. If not, the algorithm
splits up the source at the camel case parts from the right side into
a head and a tail and tries to find the corresponding property, in our
example, AddressZip and Code. If the algorithm finds a property with
that head it takes the tail and continue building the tree down from
there, splitting the tail up in the way just described. If the first
split does not match, the algorithm move the split point to the left
(Address, ZipCode) and continues.
Although this should work for most cases, it is possible for the
algorithm to select the wrong property. Suppose the Person class has
an addressZip property as well. The algorithm would match in the first
split round already and essentially choose the wrong property and
finally fail (as the type of addressZip probably has no code
property). To resolve this ambiguity you can use _ inside your method
name to manually define traversal points. So our method name would end
up like so:
List findByAddress_ZipCode(ZipCode zipCode);
Underscore is reserved character which allows you to point the right object to construct jpa query. It's used only with nested objects. For example if you would like to query by ZipCode inside Address inside you Company object.
More information can be found here
I have a normalization problem like the following:
R={
att1(nb1, nb2, nb3),
att2, val1, val2, def1, class1,
class2{notion1, notion2},
def2,col1
}
Here, attr1 is a multi-valued attribute and class2 is a composite attribute.
How do I convert R to 1NF?
Is it like the following?
R={
nb1, nb2, nb3,
att2, val1, val2, def1, class1,
notion1, notion2,
def2,col1
}
Yes, your answer is correct. As it is said in Wikipedia:
A relation is in first normal form if the domain of each attribute contains only atomic values, and the value of each attribute contains only a single value from that domain.
In other words, you cannot have attributes that:
are structured, that is contain components, or
are repeated (or both).
So, att1 and class2 must be substituted by their components.
Note that in the result relation you have different rows with the same values for all the other attributes different from nb1, nb2 and nb3.
This normal form has been introduced initially in a paper by E. Codd, in 1971: E. F. Codd, Further normalization of the database relational model, Courant Institute: Prentice-Hall, ISBN 013196741X,
A relation is in first normal form if it has the property that none of its domains has elements which are themselves sets.
(see Wikipedia citation).
This normal form is nowday presented in all the books on relational theory only for historical reasons, since this property is now considered part of the Relational Database Model. See for instance the book Fundamentals of database systems, by R. Elmasri, S. Navathe, Addison Wesley (pag.519 of the 6th edition, ISBN: 978-0-13-608620-8):
First Normal Form
First normal form (1NF) is now considered to be part of the formal definition of a relation in the basic (flat) relational model; historically, it was defined to disallow multivalued attributes, composite attributes, and their combinations. It states that the domain of an attribute must include only atomic (simple, indivisible) values and that the value of any attribute in a tuple must be a single value from the domain of that attribute. Hence, 1NF disallows having a set of values, a tuple of values, or a combination of both as an attribute value for a single tuple. In other words, 1NF disallows relations within relations or relations as attribute values within tuples. The only attribute values permitted by 1NF are single atomic (or indivisible) values.
Say I have a table called Users, which contains your typical information: Id, Name, Street, City--much like in the example here:
http://weblogs.asp.net/manavi/archive/2010/12/11/entity-association-mapping-with-code-first-part-1-one-to-one-associations.aspx.
Among other things, this article states:
"Code First has a concept of Complex Type Discovery that works based on a set of Conventions. The convention is that if Code First discovers a class where a primary key cannot be inferred, and no primary key is registered through Data Annotations or the fluent API, then the type will be automatically registered as a complex type. Complex type detection also requires that the type does not have properties that reference entity types (i.e. all the properties must be scalar types) and is not referenced from a collection property on another type." My Address class meets these criteria: it's made up of strings and isn't used anywhere else.
In the app, though (I'm not sure if this makes any difference), we're calling the Users something else--say, Techs. I want to break out User's address columns into an Address so each Tech can have its own Address. According to the article above, EF should infer this and take care of the complex type automatically. What I'm getting,though, when the context attempts to give me a Tech, is the following exception:
System.Data.EntityCommandExecutionException: An error occurred while executing t
he command definition. See the inner exception for details. ---> System.Data.Sql
Client.SqlException: Invalid column name 'Address_Street'.
Invalid column name 'Address_City'.
Invalid column name 'Address_State'.
Invalid column name 'Address_Zip'.
It looks like it's trying to make sense of the Tech.Address property, but is giving each of its sub-properties the wrong name (e.g., "Address_City" instead of "City").
Any ideas on how I can rectify this?
That is correct behavior. Default convention always prefixes properties mapped to complex type with type name. If you want to use different column names you must map them either through data annotations:
public class Address
{
[Column("City")]
public string City { get; set; }
...
}
or through fluent API:
modelBuilder.ComplexType<Address>().Property(a => a.City).HasColumnName("City");
Using sqlalchemy 0.7.2
Is there a way to find the table class from the query object? For example:
q = session.query(Customers)
how can I find Customers in q? Possible? Not Possible?
Yes. You need column_descriptions.
It's a long road to the table, though. sqlalchemy.orm.Query.column_descriptions returns a list of dicts, describing each query entity as it was given to query. in your example, there's only one entity, so you need the first item from that list. And since you're interested in the type of the query entity, rather than its' structure, you want the "type" key from that list:
q_entity = q.column_descriptions[0]['type']
assert q_entity == Customer
Accessing the table for the mapped class requires snooping around in the mapper subsystem. for that, you should use manager_of_class. The table is accessible from the manager through the mapper.mapped_table attribute:
from sqlalchemy.orm.attribute import manager_of_class
q_table = manager_of_class(q_entity).mapper.mapped_table
Resist the urge to skip strait to the mapper through Customer.__mapper__, or even Customer.__table__; That's specific to sqlalchemy.ext.declarative, and won't work with classes that are mapped by other means.
In my case, every "item" either has a property , or not. The properties can be some hundreds, so I will need , say, max 1000 true/false bits per item.
Is there a way to store those bits in one field of the item ?
If you're looking for a way to do this in a way that's searchable, then no.
A couple searchable methods (involving more than 1 column and/or table):
Use a bunch of SET columns. You're limited to 64 items (on/offs) in a set, but you cna probably figure out a way to group them.
Use 3 tables: Items (id, ...), FlagNames(id, name), and a pivot table ItemFlags(item_id, flag_id). You can then query for items with joins.
If you don't need it to be searchable, then all you need is a method to serialize your data before you put it in the database, and a unserialize it when you pull it out, then use a char, or varchar column.
Use facilities built in to your language (PHP's serialize/unserialize).
Concatenate a series of "y" and "n" characters together.
Bit-pack your values into a string (8 bits per character) in the client before making a call to the MySQL database, and unpack them when retrieving data out of the database. This is the most efficient storage mechanism (if all rows are the same, use char[x], not varchar[x]) at the expense of the data not being searchable and slightly more complicated code.
I would rather go with something like:
Properties
ID, Property
1, FirsProperty
2, SecondProperty
ItemProperties
ID, Property, Item
1021, 1, 10
1022, 2, 10
Then it would be easy to retrieve which properties are set or not with a query for any particular item.
At worst you would have to use a char(1000) [ynnynynnynynnynny...] or the like. If you're willing to pack it (for example, into hex isn't too bad) you could do it with a char(64) [hexadecimal chars].
If it is less than 64, then the SET type will work, but it seems like that's not enough.
You could use a binary type, but that's designed more for stuff like movies, etc.. so I'd not.
So yeah, it seems like your best bet is to pack it into a string, and then store that.
It should be noted that a VARCHAR would be wasting space, since you do know precisely how much space your data will take, and can allocate it exactly. (Having fixed-width rows is a good thing)
Strictly speaking you can accomplish this using the following:
$bools = array(0,1,1,0,1,0,0,1);
$for_db = serialize($array);
// Insert the serialized $for_db string into the database. You could use a text type
// make certain it could hold the entire string.
// To get it back out:
$bools = unserialize($from_db);
That said, I would strongly recommend looking at alternative solutions.
Depending on the use case you might try creating an "item" table that has a many-to-many relationship with values from an "attributes" table. This would be a standard implementation of the common Entity Attribute Value database design pattern for storing variable points of data about a common set of objects.