# Tag Info

1

Community Wiki answer generated from comments on the question by Renzo and ypercubeᵀᴹ The definition of functional dependencies requires that they must hold for every possible instance. From an instance, you cannot find the functional dependencies that hold in a certain relation schema. You also missed A → D.

3

Your decomposition is not correct, since in R2 you still have dependencies that violates the BCNF, for instance UtilisateurID → Nom (UtilisateurID is not a key of that relation). The problem is that your algorithm is not correct. When you find a dependency X → A that violates the BCNF, you should decompose a relation in two relations, the first with X+, not ...

1

Normal forms are used to eliminate or at least reduce redundancy in data, as well as to eliminate the so called insertion/deletion anomalies. The BCNF eliminates redundancies and anomalies, but decomposing a relation in BCNF sometimes has the unpleasant effect of causing the loss of one or more functional dependencies during the process. For this reason ...

0

Here's a condition that will help you in the future to check if a relation is in 3NF (it checks 2NF implicitly, i.e can be applied on any relation directly without checking 2NF) : A relation is in 3NF if for every non-trivial functional dependency(X is not a superset of Y in X->Y) the following 2 conditions hold 1) Either X is a superkey 2) or Y is a ...

1

In the book, "Garcia-Molina H., Ullman J., Widom J., Database Systems: The Complete Book. Pearson Prentice Hall, 2009", Chapter 5, "Algebraic and Logic Query Languages", on top of page 217 of the 2nd edition, there is a box titled "δ is a Special Case of γ", that explains how the duplicate removal operation δ is redundant, since it can be replaced by the use ...

2

First of all, note that the original relation is already in Third Normal Form, since each attribute is prime (each attribute is a key, actually), so that the definition of 3NF is respected. Then, note that the algorithm is incomplete. The steps are: Find a minimal basis of F, say G For each groups of FD with the same left part, X → A1, X → A2, ..., ...

1

The trick to solve this exercise it to repeat as much as possible the elements of the table. Since A is the key, you cannot repeat A, but you can, for instance, repeat two times B and C and three times D. Here is a very simple and short example (note that the functional dependencies are respected): r = +---+---+---+---+ | A | B | C | D | +---+---+---+---+ ...

1

I had to use two JOINs here but I think that this will work. You can join on the same table multiple times SELECT a.t_code, a.t_waste_water, a.t_drinking_water, b.perim_name AS waste_water_perim, c.perim_name AS drinking_water_perim FROM schema.town a JOIN schema.perimeter b ON a.t_waste_water = b.perim_code JOIN schema.perimeter c ON ...

2

In addition to Ziggy answer, if you want to make this diagram work, you need to edit it, for example you should create a third table called cleint_order and this table has primary key from Client table and idproduct from product table since one client may have one or more product and one product can be ordered from many customers. useful link: ...

1

UML class diagrams do not include relations in a class' attributes list, so when creating database tables representing those classes, the database designer must identify and specify them, much like the software developer must create the pointers and lists to support the related objects. In your diagram, Commande relates to Client but does not explicitly ...

8

The ages are discrete values OK. a Person can have any number of the 18 (assuming 0-17 years old) assigned to their account. So it's a many-to-many relationship? If so, you just decompose your data into third normal form as usual, expressing the cardinality by means of one extra relation. Example follows. The SQL dialect is not necessarily ...

0

this is an analytic problem, so you should use dimensional design here. Store the data normalized, but use a view or materialized view to give you the columns you want

2

Initially I considered creating 18 boolean fields, but this seems inefficient. If by "efficient" we mean storage size, 18 boolean columns are among the most efficient solutions possible. A boolean column occupies 1 byte and requires no alignment padding. If not-applicable ages can be NULL, it's typically less: How do completely empty columns in a ...

2

There are two key bits of information you should add to your question to get better answers: How is the data expected to be queried? How you want to use the data in your application can make a significant difference to how it is best stored. What business rules govern the range of ages a person can teach? Is it possible that someone can teach completely ...

0

Ideally, your system could comprise: a Locations table with location information and a location_id a People or Observers table with personal details and a person_id an Observations table just the way you have it and an Observer_Observations table with person_id and obs_id (i.e. your many-to-many table) The total_time column in your Observers table should ...

1

The usual notation is to write separately the grouping attributes from the aggregation functions, writing the attributes on the left of the γ symbol and the aggregation functions on the right, so your query should be something like this: employeeId, date γ MAX(salePrice)→ largetSale(Sales) This means: make a group for each different combination of ...

1

You might find this page interesting. Your schema seems to be reasonable - the only way you'll know is by writing your application and seeing if it works :-). What you initially call a "bon de commande", you later refer to as a "bon de livraison" (which makes more sense in French). You also fail to provide a definition of ContenuBL (La composistion d'un ...

Top 50 recent answers are included