Suppose we have a relation R(A,B,C,D,E) with candidate keys {A,B} , {C,D} and let E be a non prime attribute.
If there is a dependency C->E then it is partial dependency as E depends on a part of candidate key {C,D}
Is dependency BC->E partial?
A functional dependency is partial if, on removing one or more attributes from the determinant (left-hand side), you still have a dependency that holds. In your example therefore:
{C}→{E} is a full functional dependency
{C,D}→{E} is a partial functional dependency because {C}→{E}
{B,C}→{E} is a partial functional dependency because {C}→{E}
Related
What is the use case of composable_factory? It seems it is related to m_outer, but I can not find any code calling it (Searched all files in the cppwinrt directory). Many thanks!!!
composable_factory is used for constructing types that allow inheritance. In the Windows Runtime, since base class and derived classes may be in separate components, or even written in separate languages, they use COM aggregation to stitch the base and derived classes together into what appears to be, to the client, a single object. A good example of this would be if you created your own MyButton class that is not sealed / final. It would both compose with Button and be derivable by other classes.
Much like activation_factory, composable_factory serves as a specialized activation factory for instantiating objects while taking a base class to derive from during construction. You can see how that fits together with the inner & outer args here:
https://github.com/microsoft/cppwinrt/blob/c36cf05f5030726c8ada1b89fc78bd470f737032/strings/base_composable.h
I believe m_outer is typically the base class, and inner is the derived.
Ben
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 often have the problem that function and type definitions aggregate over time in a single module (we can assume that a module corresponds to a source file). At some point the source file is so big that it is barely maintenable anymore. For example, one realizes the module contains a lot of functions that are logically related to a handful of different topics, and one feels that they should be in their own modules.
The idea is to have a tool that suggests ways to split up such a module. The actual creation of new source files from the old ones could then be made automatically.
I have the follwoing:
list of functions and data types, along with their direct dependencies on other functions and types in the module.
from this, we can compute all dependencies for every item
we can do a topological sort, to make dependency groups. For example
(a, (b,c,d), e)
an item more left in the outer list does not depend on any ones further right
inner grouped items like (b,c,d) depend recursively on each other
The modules must form an acyclic hierarchy, i.e. it is not possible that module A imports module B when B or one of the modules it imports already imports A. From this it follows that (b, c, d) from the example above must not be splitted across different modules.
Now I am somehow stuck and looking for a strategy to make sensible suggestions based on the information found so far.
Of course, one possibility would be to split according to the topologically sorted list of dependency groups. However, let us assume the list starts thus:
(a, b, c, ....)
Where c depends on b and a, b on a and a on nothing. Here we could do the following:
module ABC that defines a, b and c
module A that defines a, module BC that imports A and defines b and c
module C imports A and B and defines c, module B imports A and defines b
If we simply map dependencies between functions into dependencies between modules we may end up with a module hierarchy that is too complex and fine grained.
Somehow I must take further factors into account. Maybe some desired module size, or number of imports.
Any advice, as well as pointers to existing software doing something like this are most welcome.
It sounds like you are describing Efferent and Afferent Couplings http://en.wikipedia.org/wiki/Software_package_metrics
This is a language agnostic question but I know of a few tools in Java such as JDepend (http://clarkware.com/software/JDepend.html) that will compute these metrics for you to help guide future refactorings.
enter code hereI am Preparing for my database exam.
I have a question about finding the non-trivial functional dependency for R={A,B,C,D,E,F,G}
with the given set of functional dependencies as:
A->B
A->D
C->EA
F->G
The candidiate key in this case is CF since CF+=ABCDEFG
A non-trivial functional dependency could be C->B
Is this true?If not how to calculate non-trivial functional dependency and how to prove it using Armstrong Axioms
Thank you for your patience and time
Hint:
C->EA
is equivalent to
C->E and C->A
I'm aware that Common Lisp has different binding environments for functions and variables, but I believe that it also has another binding environment for tagbody labels. Are there even more binding environments than this? If so, then is it fair to categorize Common Lisp as a Lisp-2?
These question are not meant as pedantry or bike-shedding, I only want to gain a better understanding of Common Lisp and hopefully get some pointers into where to dig deeper into its spec.
I'm aware that Common Lisp has different binding environments for
functions and variables,
That would be namespaces, according to the HyperSpec:
namespace n. 1. bindings whose denotations are restricted to a
particular kind. The bindings of names to tags is the tag
namespace.'' 2. any mapping whose domain is a set of names.A
package defines a namespace.''
(Point 1.)
but I believe that it also has another binding environment for tagbody
labels. Are there even more binding environments than this?
Yes, there are more namespaces. I even remember a little snippet exposing most of them, but unfortunately, I can't find it anymore¹. It at least exposed variable, function, tag, and block namespaces, but maybe also types and declarations were included. There is also another SO answer that lists these namespaces.
If so, then is it fair to categorize Common Lisp as a Lisp-2?
In the comments to the above linked answer, Rainer Joswig agrees that the "general debate is about Lisp-1 against Lisp-n".
The "2" might be due to the relative importance of the distinction between value and function slots, or because the objects of the other namespaces aren't first-class objects. For example in the Gabriel/Pitman paper referenced in the other answer:
There is really a larger number of namespaces than just the two that
are discussed here. As we noted earlier, other namespaces include at
least those of blocks and tags; type names and declaration names are
often considered namespaces. Thus, the names Lisp1 and Lisp2, which we
have been using are misleading. The names Lisp5 and Lisp6 might be
more appropriate.
and:
In this paper, there are two namespaces of concern, which we
shall term the "value namespace" and the "function namespace." Other
namespaces include tag names (used by TAGBODY and GO) and block names
(used by BLOCK and RETURN-FROM), but the objects in the location parts
of their bindings are not first-class Lisp objects.
¹) PAIP, p. 837:
(defun f (f)
(block f
(tagbody
f (catch 'f
(if (typep f 'f)
(throw 'f (go f)))
(funcall #'f (get (symbol-value 'f) 'f))))))
In PAIP, Peter Norvig says "Common Lisp has at least seven name spaces" (p. 836).
The seven he lists are:
functions and macros
variables
special variables
data types
label for go statements within a tagbody
a block name for return-from statements within a block
symbols inside a quoted expression
Peter Seibel makes a great point in his comp.lang.lisp post about "compiler" versus "library" namespaces. I think all of Norvig's seven namespaces are "compiler" namespaces.
See for example this old discussion post from comp.lang.lisp:
http://coding.derkeiler.com/Archive/Lisp/comp.lang.lisp/2004-04/0737.html
Yes - http://www.lispworks.com/documentation/lw51/CLHS/Body/t_symbol.htm#symbol specifies a separate value cell and function cell, consonant with a lisp-2.
There is also a property list, but as there is no context in which a symbol "naturally" refers to its property list, it is not usual to describe CL as a lisp-3 (in fact, I am not aware of any language usually so designated).