I am learning the functional dependencies concept in IIT lectures.
In that lecture they said there are three types of functional dependencies. They are
Trivial functional dependency
Augmented Functional dependency
Transitive functional dependency
I know how to find the functional dependency. But I don't know that functional dependency is which type.
Please explain with examples for the functional dependency types.
Trivial functional dependency is easiest to understand.
A functional dependency A1A2....An->B
is said to be trivial if B is one of A’s.
To make it non-trivial just remove from the right side of an FD those attributes that appear on the left. (trivial dependency rule)
Augmented functional dependency is basically
when X->Y holds and W is a set of attributes, then WX->WY also holds.
Let me clarify the above two a bit more.
Given a dependency A1A2....Am->B1B2....Bn we can say it is:
Trivial if the B's are subset of A's.
Augmented(or maybe non-trivial) if at least one of the B's is not among the A's
Completely non-trivial if none of the B’s is also one of the A’s
3. Transitive functional dependency can occur only in a relation that has 3 or more attributes.Let A, B, and C designate three distinct attributes (or distinct collections of attributes) in the relation. Then given A->B and B->C then A->C is a transitive functional dependency.
Related
When modeling a domain using types, in which situations do traits or type classes have a clear advantage over the other?
In other words: which relationships or constraints cannot be (fully) expressed/represented with one of the two, or would require more boilerplate, spurious degrees of freedom, etc., using one of the two?
In order for this question not to be subjective, please provide concrete examples illustrating cases (or a theoretical justification).
When I write Java code, I found annotation based libraries are very popular, e.g. hibernate, Jackson, Gson, Spring-MVC. But in Scala, most of the popular libraries are not providing annotations, or provided but recommend non-annotation approaches, e.g. squerly, slick, argonaut, unfiltered, etc.
Sometimes, I found the annotations are easier to read and maintain, but why people are not so interested in them?
One reason is that annotations often have to be used at declaration-site. Hence, you have to "pollute" your domain models with code not relevant to your business logic. Solutions based on macros or type classes on the other hand are usually applied on use-site. This allows higher reusability of your domain models.
E.g., what if you need different serialization logic for different tasks? With annotations you have usually no other choice than implementing an additional representation of your model with modified annotations. With type classes (probably automatically derived through macros), you have to just implement another instance and inject it accordingly to your needs.
Macros and implicits can often be used as a substitute for annotations and have the benefit of being statically checked.
I read somewhere that 1NF - 3NF deal with functional dependency, and that the Higher Normal Forms focus on another aspect of database relationships, but I can't remember what. Does anyone know the answer to this?
1NF - 3NF deal with function dependency. BCNF - 5NF deal with ______?
My best educated guess is non-tivial / multivalued dependencies.
Is that correct, or am I way off base?
BCNF deals with functional dependencies.
4NF deals with multivalued dependencies.
5NF deals with join dependencies. 6NF deals with join dependencies in a more general way.
Fantom supports provably immutable classes. The advantages of the compiler knowing a class is immutable must be numerous, not the least of which would be guaranteed immutable messages passed between actors. Fantom's approach seems straightforward - what difficulties would it pose for Scala?
There's more interest on Scala side on tracking side effects, which is a much harder proposition, than simply immutability.
Immutability in itself isn't as relevant as referential transparency, and, as a matter of fact, some of Scala's immutable collections would not pass muster on an "proven immutable" test because, in fact, they are not. They are immutable as far as anyone can observer from the outside, but they have mutable fields for various purposes.
One such example is List's subclass :: (the class that makes up everything in a list but the empty list), in which the fields for head and tail are actually mutable. This is done that way so that a List can be composed efficiently in FIFO order -- see ListBuffer and its toList method.
Regardless, while it would be interesting to have a guarantee of immutability, such things are really more of a artifact of languages where mutability is the default. It doesn't come up as a practical concern when programming in Scala, in my experience.
While the approach may be straightforward,
its guarantees can be broken by reflection;
it requires quite a bit of effort, which the Scala team may think not worth it or not a priority.
We are developing an extension (in C# .NET env.) for a GIS application, which will has predefined types
for modeling the real world objects, start from GenericObject, and goes to more specific types like Pipe and Road with their detailed properties and methods like BottomOfPipe, Diameter and so on.
Surely, there will be an Object Model, Interfaces, Inheritance and lots of other essential parts in the TypeLibrary, and by now we fixed some of them. But as you may know, designing an Object Model is a very ambiguous work, and (I as much as I know), can be done in many different ways and many different results and weaknesses.
Is there any distinct rules in designing O.M.: the Hierarchy, the way of defining Interfaces, abstract and coclasses enums?
Any suggestion, reference or practice?
A couple of good ones:
SOLID
Single responsibility principle
Open/closed principle
Liskoff substitution principle
Interface segregation principle
Dependency inversion principle
More information and more principles here:
http://mmiika.wordpress.com/oo-design-principles/
Check out Domain-Driven Design: Tackling Complexity in the Heart of Software. I think it will answer your questions.
what they said, plus it looks like you are modeling real-world entities, so:
restrict your object model to exactly match the real-world entities.
You can use inheritance and components to reduce the code/model, but only in ways that make sense with the underlying domain.
For example, a Pipe class with a Diameter property would make sense, while a DiameterizedObject class (with a Diameter property) with a GeometryType property of GeometryType.Pipe would not. Both models could be made to work, but the former clearly corresponds to the problem domain, while the latter implements an artificial (non-real-world) perspective.
One additional clue: you know you've got the model right when you find yourself discovering new features in the code that you didn't plan from the start - they just 'naturally' fall out of the model. For example, your model may have Pipe and Junction classes (as connectivity adapters) sufficient to solve the immediate problem of (say) joining different-diameter pipes to each other and calculating flow rates, maximum pressures, and structural integrity. You later realize that since you modeled the structural and connectivity properties of the Pipes and Junctions accurately (within the requirements of the domain) you can also create a JungleGym object from connected pipes and correctly calculate how much structural load it will bear.
This is an extreme example, but it should get the point across: correct object models support extension and often manifest beneficial unexpected properties and features (not bugs!).
The Liskov Substitution Principle, often expressed in terms of "is-a".
Many examples of OOP would be better off making use of "has-a" (in c++ private inheritance or explicit composition) rather than public inheritance ("is-a")
Getting Inheritance right is hard. Doing so with interfaces (pure virtual classes) is often easier than for base/sub classes
Check out the "principles" of Object oriented design. These have guidelines for all the questions you ask.
References:
"Object oriented software construction" by Robert Martin
http://www.objectmentor.com/resources/publishedArticles.html
Checkout the "Design Principles" articles at the above site. They are the best references available.
"BottomOfPipe"? Is that another way of saying the depth of the Pipe below the Road?
Any kind of design is difficult and can be done different ways. There are no guarantees that your design will work when you create it.
The advantage that people who design ball bearings and such have is many more years of experience and data to determine what works and what does not. Software doesn't have as much time or hard data.
Here's some advice:
Inheritance means IS-A. If that doesn't hold, don't use inheritance.
A deep hierarchy is probably a sign of trouble.
From Scott Meyers: Make non-leaf classes interfaces or abstract.
Prefer composition to inheritance.