Operator(opCode,opName)
Journey(opCode,destionationCode,price)
Destination(destinationCode,destinationName,distance)
write a Relational Algebra to list all the name that do not have operator
my attempt
T1- project opCode(Operator) - project opCode(Journey)
project destinationName(T1 natural join Destination)
π<destinationName>( Destination ⋈
(π<destinationCode>(Destination) - π<destinationCode>(Journey) ))
Or it might be more succinct to use AntiJoin aka AntiSemiJoin aka SemiDifference aka Not Matching -- depending if your dialect of the Algebra allows it
π<destinationName>( Destination ▷ Journey )
Related
Stack: node 16 / Express+TS / TypeORM^0.2.45
I happen to have two databases mysql and oracle that require interoperability. Some queries depend on vendor-specific functions like date_diff(a, b) vs a - b and year(a) vs extract(year from a)... I couldn't find any utils that help translating that; is there any built-in function or lib that could do the trick before I resort to implementing my own?
Let's say I have write transformers (e.g. data presentation layer) in such ways that the usage looks like these (using PHP syntax):
A: $userTransformer can be used for different users, kind of like a helper.
$userTransformer->transform($user) // Outputs user data for a webpage
B: $userTransformer is specifically for one user.
$userTransformer->transform() // Same user output
Are there terms describing the ways these transformer classes are designed? A doesn't have any dependency during instantiation, whereas B requires $user to be instantiated. Personally, I prefer B, and I'm trying to look up some literature regarding this.
In the language of UML, consider the difference between dependency and association.
Dependency:
$userTransformer->transform($user) // user is just a method argument
Association:
$userTransformer->transform() // user is a class field
There are two forms of association: aggregation and composition. Personally, when designing class relationships, I think in terms of "strength of relationships" where:
dependency < aggregation < composition
I understood the concept of BCNF very well so someone gives me a relationship in this format like
R = {P, Q, S}
F = {PQ->S, PS->Q, QS->P}
I can easily say that the relation is in BCNF since all the keys on left hand side are also super keys. But If I get a real world questions like the below image:
then how will I determine whether this schema is in BCNF? How will I create functional dependencies from the schema and then found out about super keys? could anyone give me some pointers to solve such questions?
If you convert the schema into :
Code -> City, State
Flightnum -> .....
model -> ...
cid -> ....
Cid, flightnum, date -> ...
then obviously this is not in BCNF but the answer is that the following schema is BCNF, and I am not able understood how they derived the equation for it.
Informally, a schema is in BCNF if all of its relations are in BCNF.
How will I create functional dependencies from the schema . . .
Without any other context, I'd assume that underlined attributes in the image are attributes in the primary key.
So I'd read that image as saying
code->city, state
cid->name, city
etc.
Those are your functional dependencies.
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
If I've got Foo with a property of type Bar. Both are persisted in a database which can be retrieved by an ID. (The IDs are actually used in the line of business by customer service claims. So they're not just index placeholders.) I could take the approach shown with b1 or b2.
Chaining entities together scares me since if you push that too far, it's easy to get Null's popping up. On the other hand, having the ID show up everywhere seems like it's adding unnecessary wordiness.
int fooKey = 123;
Foo f = new Foo(fooKey);
Bar b1 = new Bar(Foo.BarID); //This?
Bar b2 = Foo.Bar; // Or This?
Note: This is NOT about the .NET Entity framework. The word entity is used here in the general sense.
As a general rule I try to avoid chaining, because it usually introduces unncessary tight coupling. All depends on the context, but in terms of business objects it might be a good idea to keep the entities loosely coupled so they can grow independently.
In the example you provide I don't think tight coupling is warranted. If the intersection was greater this might be warranted, but this isn't the general case with Business entities, I've found.
Take a look at the way MSFT implemented LINQ to SQL. They let you set either/or. Their mapper is smart enough to expose both properties and lazy-load as necessary. IMO you should go the simplest way (use an ID) or use an O/R mapper like Hibernate/NHibernate, Linq to SQL, or Linq to Entities if you want fanciness.