database-normalization

Warning: this is an exercise to understand better JSON database design in Firebase it is not necessarily realistic I have got a two ways relationship between users and door keys. I would like to understand: how to represent this relationship visually ( I can imagine it only as two separate trees ) how this would work on Firebase, would both users and door-keys be child of a parent node "myparentnodename"? If I model the database in this way it feels highly inefficient because every time I would query the child node "users" I would get all the users back. Or am I wrong? Is it possible to only

Suppose the relation R( K, L, M, N, P) , and the functional dependencies that hold on R are: - L -> P - MP -> K - KM -> P - LM -> N Suppose we decompose it into 3 relations as follows: - R1(K, L, M) - R2(L, M, N) - R3(K, M, P) How can we tell whether this decomposition is lossless? I used this example R1 ∩ R2 = {L, M}, R2 ∩ R3 = {M}, R1 ∩ R3 = {K,M} we use functional dependencies, and this is not lossless in my opinion, but a little bit confused. It helps if we demystify the concept of lossless decomposition a bit: it really just means that joining R1, R2 and R3 should yield the original R. Do

I have a table called "Person" with the following fields Id (Primary Key) FirstName LastName DateOfBirth City State Country Should things like City, or State or Country be normalized and broken up into their own table and then this table have CityId and StateId columns. We were having a debate whether this was a good or bad decision. To add, I do have a City and a State table (for other reasons not related to this person table). I am curious around answers with or without this additional fact. Normalizing address into a hierarchy is a questionable proposition. It really depends on what you

What is a KISS (Keep it Simple, Stupid) way to remember what Boyce-Codd normal form is and how to take a unnormalized table and BCNF it? Wikipedia 's info: not terribly helpful for me. Chris Date's definition is actually quite good, so long as you understand what he means: Each attribute Your data must be broken into separate, distinct attributes/columns/values which do not depend on any other attributes. Your full name is an attribute. Your birthdate is an attribute. Your age is not an attribute, it depends on the current date which is not part of your birthdate. must represent a fact Each

Just curious: is there some reason why one cannot do all necessary normalizations in a single step? Isnt normalization ultimately the redrawing of the Functional Dependency (FD) graph? We start out with an FD diagram/graph and we want to end up with a graph (vertices are attributes, there is an edge between attributes a,b if b is FD on a ) representing a relation in (Edit) BCNF ? EDIT: What I mean is : we start with a FD graph , which is a graph pairing attributes a,b iff b is FD on A, i.e., we join a and b with an edge iff b=f(a). From this graph we want to obtain a graph (FD)_2 with certain

There is an username/password verification step first then the database has following structure ^ is primary key * uses foreign key 1.StudentDetails table =========================================================================== ID^| Username | Password | Email | Address * | Website |Comments ====+============+==========+=============+===========+=========+========== 1 | xxxxxxxxxx | xxxxxxx | xx@xxx.xxx | 1 | http:// | text 2.Submissions table =========================================================================================== ID^|Username*|SubmitDate|SelectedCourse*|Price*|Promotion

According to my understanding - and correct me if I'm wrong - "Normalization" is the process of removing the redundant data from the database-desing However, when I was trying to learn about database optimizing/tuning for performance, I encountered that Mr. Rick James recommend against normalizing continuous values such as (INTS, FLOATS, DATETIME, ...) "Normalize, but don't over-normalize." In particular, do not normalize datetimes or floats or other "continuous" values. source Sure purists say normalize time. That is a big mistake. Generally, "continuous" values should not be normalized

From the Database Management Systems book: given the relation SNLRWH (each letter denotes an attribute) and the following functional dependencies: S->SNLRWH (S is the PK) R->W My attempt: First, it is not 3NF: for the second FD, neither R contains W, nor R contains a key, nor W is part of a key. Second, it is/not 2NF. If we examine the second FD, W is dependent on R, which in turn is not part of a key. STUCK. 2NF is violated if some proper subset of a candidate key appears as a determinant on the left hand side of one of your (non-trivial) dependencies. Ask yourself whether any of your