Tag Info

New answers tagged

0

No, your decomposition is noteven in 2nd normal form. {A -> B,C} {E -> F} {D -> I} {A,D -> G} {G -> H} A, B and D cannot be found on the right side of a dependency, so they are members of every key. {A, D, E} generate all attributes, so it is a superkey and therefor the only minimal key But your decomposition is wrong AA is not a key of R1A, because G ...


3

Which of the two options is the best? The relational design is clearly superior to the hierarchical design used in the NoSQL example. A database schema designed using relational principles does not favor one access path over another. Each table represents a real world entity type and through the use of relational algebra queries of arbitrary ...


1

As you cannot use the vendor name as identifier, since it may be duplicated (as it happens with the name of a person), you need a true identifier to be set upon creation. When someone identifies themselves in your system, they cannot identify by their name, since it is not enough to uniquely identify them. Thus you don't have any other option than assigning ...


0

You will need several tables to accomplish your design. One for ads, one for categories and one for the ad properties (make, manufacturer, book title, isbn, etc...). Here is a sample design: Table Advertisement. This will contain the ad instances. ID - primary key Title Category_ID - foreign key to Category.ID. Tells us the ad category. Description ...


0

Store the information in tabular format. It will also help you in validating at application level. Store your field type in property table. and values in columns table. Hope it helps.


0

I would avoid having completely separate tables for each ad type, that would be bad design (you'd end up having to UNION them all together in just about every query). Also avoid having all the fields possible in one table as that would be inefficient also, especially if your database doesn't support sparse rows. The usual technique for this sort of problem ...


1

I would favor your first arrangement where you have an Item_Id FK in the Coupon table. You will be able to enforce the "One coupon per item rule" through a unique constraint on the Item_Id column in your Coupon table. You will be able to easily allow multiple coupons per item if business decides to change their mind. Like you said you can easily select ...


2

The pattern you describe is known as "friend of a friend." Here are a couple of answers on SO which may guide you. In the relational database world the friends would be found by following foreign keys. Document DBs, however, eschew explicit foreign keys enforced in the DBMS and join-like functionality in favour of other benefits. It is down to your ...


0

Oracle is a SQL DBMS not a truly relational database. It implements as its logical model of data a variant of SQL. Its architecture was developed in the late 1970s along the same lines as IBM's System R which was an initial implementation of a DBMS based on the relational model using SQL as the data sub-language. This short background is necessary to ...


1

Are you a member of db_owner? See this: To use Database Diagram Designer, it must first be set up by a member of the db_owner role to control access to diagrams (https://msdn.microsoft.com/en-us/library/ms189279%28v=SQL.100%29.aspx)


2

Your current diagram is great as long as everyone only has one address, and a max of two phone numbers (apart from a fax). One simple way this schema falls apart is if you have a client with a street address for their location, but a PO Box for their mailing address. This is a fairly common setup for rural communities in the United States. When I lived ...


0

Huh? Sounds like the textbooks are making things too complicated, with too much terminology. Yes, "country" involves a many:1 relationship. Yes there are 2 tables. Yes, country_id is in both tables. OK, you could have a FK relationship. Or you could simply make sure you insert into Countries whenever you come across a new country.


0

What you have in the image is great. It's a place to put contact information for both of those other entities. I don't even understand why you'd need to have a contact type... You don't want to create two tables that contain the same columns under almost any circumstances.


1

I want to persist contact details for persons. Since persons could include both staff and clients, the natural step would be to have a single table of contacts for all persons. As oNare suggested in a comment above, just create a contactType field in which you can assign either person type. This solution has the benefit of adding in future, if a need ...



Top 50 recent answers are included