New answers tagged

2

Todd's answer is excellent. Here's an over simplified answer. There are pros and cons to normalization, beyond 1NF. The biggest pro to normalization is that it prevents mutually contradictory facts from being stored in a database. when the same fact is stored in more than one place, it becomes possible to store mutually contradictory versions of that ...


5

We have defined via comments the following significant facts about your scenario: A Product can be offered by zero-one-or-many Suppliers, and a Supplier offers one-to-many Products. A Supplier and a Vendor are one and the same entity type, i.e., they represent the same set of things that have identical attributes. An Individual (or Person) can never ...


2

The important thing about the 2NF is that in each (non trivial) dependency the determinant should not be a proper subset of a key. In the example, the determinant of AB->C is the full key, while the determinant of C->D is C, which is no part of any key. So the schema is obviously in 2NF.


3

Your question really is not about normalization. Instead it is about specialization vs. generalization with respect to design. Let me give some background to show why this is the case. Background A table is a relational (R-Table) table, and thus normalized (meaning in 1NF by definition) if in its design a discipline is followed that ensures: Distinct, ...


2

You want to track changes to the items at the item level so your item table would have a key that represents the 'item_id' and something else that distinguishes each state change for that item - you could use a timestamp or a counter or a flag. Let's generically call it 'version attribute'. Table Design [LIST] LIST_ID LIST_NAME -- other ...


1

Since your starting position is fixed (after the 2nd _), you can use an Instr() function to find the position of the 3rd _, and just take the characters between. Instr() returns the postion of the first instance of a character in a string. If the character is not found, it'll return 0. Note, Access considers the first character position to be 1. Give this ...


3

Assuming that each month is universally identified by number (1 is January, 2 is February, etc.), it is useless to have a table that store the first twelve numbers, so you could have a single table, with the following attributes: CREATE TABLE month_loc ( month_number INT NOT NULL, name VARCHAR(200) NOT NULL, description ...


2

For the time being I have settled on not normalizing the string arrays, and just keeping them as string columns as it has not been a problem so far. While I realize that I do not have any userbase yet to accurately judge performance, I have come to realize that it might be premature to try and performance optimize this problem until I run into actual ...


1

You are asking: I have a question, how did we know that R1 was not in BCNF and needs to be decomposed? In the BCNF Decomposition Algorithm, when a relation is decomposed, one should find the dependencies of the subschemas, in this case R1(ACDE) and R2(BCD). Let’s start from R1. To find the dependencies that hold in R1, one should actually project the ...


2

The algorithm that decomposes a relation schema R to produce the BCNF operates in the following way: at each step, a dependency is searched that violates the Normal Form. If one if found (as A -> B C D E in the example), the schema is decomposed in two subschemas, one with the attributes of A+, and the other one with the attributes of the relation R minus ...


5

Your schema has three (candidate) keys: HI IJ IK While it is immediate to discover tha HI is a candidate key since it determines all the other attributes, you can see that this is true also for IJ and IK by calculating the closure of those attributes: IJ+ = IJ IJ+ = IJKL (by adding the right part of J → KL) IJ+ = IJKLH (by adding the rigth part of ...


2

Community Wiki answer generated from a comment on the question by @a-horse-with-no-name You might want to look into Postgres' hstore data type. A very efficient (indexable!) key/value store. Plus it has index types that efficiently support like '%ab%' PostgreSQL hstore documentation


-2

You are trying to find out possible candidate keys. HI is the only possible candidate key or prime attribute since it independently identifies all other attributes or fields due to the functional dependency HI -> JKLMNO. All the other attributes are non-prime attributes. Again, here HI is a composite candidate key and both H and I are key attributes ...


0

1) left join is slower than inner join. It is first reason. The second add special indexes for optimization query. Use explain plan of query 2)if you want to use result table then I recommend you use material view. It will be faster and you can don't think about length of fields. p.s. View is not a table so you will save you time instead your insert in ...


2

The first solution is clearly more efficient than the second one, because you don't need to do the join (every join slows down a query, more or less depending on the access plan generated by the system). More, I think the second solution has some problem, since from the schema it seems that you are using the column id inside mssg_grp as foreign key ...



Top 50 recent answers are included