Tag Info

New answers tagged

1

My team once had to build a database for reporting financials with alternative time windows, including fiscal years, fiscal quarters, and fiscal months. The relationship between dates and these units was documented, but really messy. So here is what we did. We created a table, call it Almanac, with one row per date. (In reality, we had one row per work ...


1

As far as I understand the theory, if you can join your decompositions and arrive back at your relation with no loss, that's it. It looks to me like AB, A, B, F, D are the keys to do so.


0

The following two FD's violate 2NF: A->C B->D We can create new relationships based upon those FD's: (AC;A->C), (BD;B->D), (ABE;AB->E). This set of relationships now satisfies 2NF (and also 3NF and BCNF).


0

The accepted answer is incorrect; the answers given by @sqlvogel and @gbn are correct. Surrogate keys are non-domain-driven keys that stand-in for natural keys (those with functional dependencies that derive from the domain). For instance, we might have a table with independent, non-overlapping keys (a table named People with id, ssn, and email as keys). ...


1

First, a name like 'entities' is too vague. The common name for org or individual is 'parties'. Second, people can have zero, one, or many addresses, and can share the same address. It's a many2many relationship. I would do it like this (using STI here, but break it out to CTI if you like): PARTIES id type (org or individual) name ADDRESSES id type ...


4

A candidate key is a set of attributes that constitute a minimal superkey. Two candidate keys, A and B, are said to overlap if they have some attributes in common, i.e.: A ∩ B is non-empty. In your case, MN and NO would be overlapping candidate keys in R. Because of the minimality (irreducibility) requirement one candidate key can never be a subset of ...


3

You're right on the money with the possible candidate keys, vikkyhacks. Overlapping candidate keys are composite (consist of more than one attribute) candidate keys with at least one attribute in common. So your overlapping candidate keys are NM and NO (they share N). It may also help to have an example you can really wrap your head around. The only time ...


1

If I understand your dilemma correctly, you have: Two tables, each of which can have a comment One of the tables is optional, i.e. it may not have an entry to correspond to the other For the second table, the comment is also optional, such that even if the second table has a record to match the first, the comment in the second may just "default" to a copy ...


4

When designing a database, normalization is a process undertaken when producing the logical model i.e. the relational data model. Performance is an attribute of the physical model; the implementation of the logical model on a particular DataBase Management System. You cannot "over-normalize" a relational data model. Either the relational data model is in ...


1

I think the answer here is at least very close to, if not the same as, the answer to "how close to a particular ideal should we strive for to reach this goal?" Different steps along the way in the development life cycle, different disciplines (within software development: application programming, database design/programming, UI, QA, etc) have various ideals. ...


1

You may want to normalize out the comments field to allow for a comments chain. This may have additional fields such as userid and date. This might result in a table tracking actions on issues. If this is not part of your design, I wouldn't normalize the comments field out. It appears you have an optional 1-1 relationship between the status checks and ...


1

For user details, I would suggest to have two tables and one for saving User Address User_Account_Details(user_id, primary_email, secondary_email, password) User_Personal_Details(user_id, first_name, last_name, profile_picture, display_name) User_Address(user_id,country, city) User_Statistics(user_id, trips_count, likes_count, ...


1

You don't need four tables for the user account data. Each user only has one primary email, one secondary email, one first name, one profile picture, one count of trips etc. If there's only one of each entry per user, why not put them all in the same table? You can set a lot of the fields to be nullable so that they don't all have to be filled in, and you ...


1

The first three FD's combine to give MNOP -> L so MNOP is one possible candidate key, CK1. Similarly the last three FD's combine to give NOPL -> M so NOPL is another possible candidate key, CK2. However CK1 and CK2 have columns NOP in common, making them overlapping candidate keys.



Top 50 recent answers are included