Entity-relationship model diagrams in Visio

One way to do this is by creating a Unique Index on the column.

1. Click the table on design surface to select the table
2. Click Indexes
3. Create new index column, by default indexes are non-unique, the next step fixes this
4. In the 2nd drop-down list, select Unique Index (VISIO offer 3 types)

There should be a way to display AKn of the left hand column of the design surface, but I don't know how to do this.

Three points:

First, you need to use JOIN to good advantage, so as to retrieve the joined data that you want with one trip to the database, instead of repetitive trips to the database. As James Anderson correctly pointed out, this is what relational databases are all about.

However, if you are just learning how to use a database in SQL, then using a database of your own design may take you down the wrong trail. The database needs to be designed well to exploit the full power of JOIN, and of two other relational operators, known as restrict and project in relational math. The SQL buzzwords are WHERE, DISTINCT, and GROUP BY.

Second, the relationship between packages and products is your basic bill-of-materials case. This case has been extensively studied in practice over the last forty years. There's no need for you to reinvent the wheel. However, if you add the possibility that packages can be composed of other packages, then the BOM problem becomes a recursive one. SQL is not built for recursion, but there are workarounds.

If you come up to speed on the nested-set technique for designing containment hierarchies, like BOM, then you reduce what would have been a recursive query into a simple SQL query that the database server can decompose into a simple reiterative process for you. Nested-set is not ultimately complicated, but there is a learning curve here.

Third, the relationship between order details and products or packages is not really a ternary relationship, in the way that term is usually used. Each order detail references an order (the parent), and either a product or a package. This either-or situation is your typical class-subclass (type-subtype) situation, rather than a true ternary relationship. Unfortunately, vanilla SQL is not good at inheritance. You could use extensions to SQL peculiar to your DBMS, if it has them, or you could use one of two techniques, called "single table inheritance" or "class table inheritance". I like Fowler's treatment of this subject.

There's plenty to learn here. You sound like a smart programmer, so you should be able to learn it fast. Just don't assume you already know it. Maybe you do, maybe you don't.