How to make the database more concise

database-design

I am writing an application for Android using SQLite (backed by ORMlite if it matters). So far I'm in the conceptual stage and working on the database design. The database is being designed to contain a collection of assets that are registered to one or more users. I have never worked on any data outside of SQLite and even then I have only made a few very small databases. As such I am not sure that my I handling this design correctly. As I expand on my design, it is beginning to look like a mess. My questions are:

Am I designing this database in too much of an ObjectOriented fashion? As a java programmer, this is just how it makes sense to design the database.
Is there any way to make the database look less like a mess?
Am I even on the correct track?

For reference here is an earlier more easy to read protoype of the database design. No typings have been assigned yet, sorry.

The previous database design

Here is a more updated visualisation of my problem.

The current database design

Best Answer

This is more of a comment, but since this is a lengthy response that's worth mentioning, I'm posting it as an answer.

Your database looks sufficient for your needs. (Well, as best can be assumed from the diagram.) I assume that the UserAccount table has a one-to-many relationship between the four tables Vehicle, Book, VideoGame and Movie (from here on, the V-B-V-M tables.) Next, I assume that the Asset table has a one-to-one relationship with each link between the V-B-V-M table entries. With this information, I would recommend moving the UserAccount_id from each V-B-V-M table, to the AssetTable.

Next, it seems that Asset is always associated with one of the four V-B-V-M tables. Considering this type of setup, I would recommend creating an additional table-- AssetType.

+-----------+
| AssetType |
+-----------+
| id        |
| typeDesc  |
+-----------+

Next, update the Asset table and each V-B-V-M tables to include a AssetType_ID field. the AssetType table should include one entry, for each type of asset. In this case, Vehicle, Book, Video Game and Movie, each with a unique description and ID.

You may want to do this for a couple reasons-- First, you can now query the Asset table and discern what type of asset is stored in a specific record, without having to link the data to your four other V-B-V-M tables. This will speed up your querying of the data, when all of the information from your four tables isn't needed. Second, this also provides an easy means of linking in a textual description of the type of asset associated with the Asset entry. Again, without having to link to the V-B-V-M tables to figure that out.

Last, you may want to consider handling the barcode data differently. If barcode is a simple look-up, you can add it to the asset table. However, if barcode values have to be unique, keeping it in a secondary table is necessary because you'd have to put a constraint on the database. You could do this if it was integrated in the Asset table, however, your vehicle data would cause problems because vehicles do not have barcodes. To my knowledge most, if not all, major database engines won't allow you to define a unique field, that also allows null values because, then, the data is no longer unique.

You might be inclined to think that you could combine the Barcode field with the VIN. Since VINs are unique and Barcodes are unique, and neither should be the same, why can't they be combined into one field on the Asset table, which allow you to drop the additional Barcode table. I wouldn't recommend this because I think it gives the data less "focus".

Yes, it is a form of unique object ID but barcodes are barcodes and VINs are VINs-- the concept behind both is completely different and consolidating the two can become confusing with time. Furthermore, if you expand your project in the future, it could cause collisions. Technically, I don't see a big problem with that (in your case) but I'd still highly recommend avoiding that option.

Also, I would also add the assetType_id to the Barcode table, for the same reasons you added it to the Asset table.

Related Solutions

Database design advice

                                                  +------------ --- ---+
                                                  | Assembly options   |
+------------+------------+----------+------------+---+---+---+ --- +--+
| assembly ▼ | unit cost  | quantity | total cost | 1 | 2 | 3 |     |50|
+------------+------------+----------+------------+---+---+---+ --- +--+
| VSD55      | £10'000    | 2        | £20'000    | 1 | 1 |   |     |  |

If somebody handed that quote to me, my first question would be "What's option 1 for the VSD55?" The answer would be "I don't know." That information isn't on the quote. In the unlikely event that person got to field a second question, that question would be "What does it cost?" Again, the answer would be "I don't know." A very disturbing silence would follow immediately, during which the person who handed me the quote would imagine how much better it might feel to be run over by a train.

Options must be line items on the quote, along with their unit price, quantity, and total price. Options must be named, not numbered. They should appear directly under their parent assembly, too, not scattered all over hell and half of Georgia.

If you want a shot at my money, you'd better make it crystal clear what I'm supposed to be getting for my money.

There's nothing (much) wrong with 50 check boxes on a user-interface form. That makes it easy to pick options. But the UI code should read the checkboxes and insert the right information into normalized tables.

Why Apply Constraints in Database Rather Than Code?

Some constraints are best enforced in the database, and some are best enforced in the application.

Constraints that are best enforced in the database are usually there because they are fundamental to the structure of the data model, such as a foreign key contraint to ensure that a product has a valid category_id.

Constraints that are enforced in an application might not be fundamental to the data model, such as all FooBar products must be blue - but later someone might decide that FooBars can also be yellow. This is application logic that doesn't really need to be in the database, though you could create a separate colours table and the database can require that the product reference a valid entry from that table. BUT the decision that the only record in colours has the value blue would still come from somewhere outside the database.

Consider what would happen if you had no constraints in the database, and required them to all be enforced in the application. What would happen if you had more than one application that needed to work with the data? What would your data look like if the different applications decide to enforce contraints differently?

Your example shows a situation where it might have been more beneficial to have the constraint in the application rather than in the database, but perhaps there was a fundamental problem with the initial data model being too restrictive and inflexible?

Best Answer

Related Solutions

Database design advice

Why Apply Constraints in Database Rather Than Code?

Related Question