I'll give you the off-the-cuff perspective of a guy who got his degree in piano and then spent the next 30 years in software design. :)
Let me say first that it is important that you understand that the manner in which the data are stored is not the same thing as the manner in which they are displayed. It looks like you have a pretty good start on the way that they are displayed.
Now, are you asking to have a user fill up a database with chords, or put in the characteristics of a chord and get output as to how the chord is spelled? The first is what you're implying, but the second might be more useful. I'll assume the second, and give you my first impression of how I would go about it.
I would consider starting this way. Allow the user to type in the letter A-G. Have two option buttons (radio buttons) in a set, one for sharp and one for flat. Then use another set of option buttons for major, minor, dimished, and augmented. Finally, have a check box for 7th.
Leave other chords until you get these basics working. This will give you all of the triads and all the 7th chords.
Now, there are two ways to store the data. A "flat" database would simply have a record for each different chord, which would have the spelling of the chord. A "normalized" database would have three separate tables: one for chords, one for notes, and one for which notes go with which chords. Notes (a table called Notes) has two fields: a key (just a number, a different number for each record or row in the table) and a note name. This table contains all the different possible notes in the scale, including all the enharmonic ones. (Enharmonic notes are notes that are spelled differently but are the same pitch, for example F# and Gb.) Include all the double sharps and flats as well; you'll need them for augmented and diminished chords with a sharp or flat root. For example, Ab diminished is Ab-Cb-Ebb, and G# augmented is G#-B#-Dx. Then, store all the chords in a Chords table. (Skip chords whose root is a double sharp or flat; they theoretically exist but come up rarely if at all in practice) Each record in the Chords table has two fields: a key and the name of the chord. Finally, you tie these together with a ChordNotes table. This one has three fields: the key of the Chords table and the key of the Notes table, and also a number which shows the place in the chord for that note, from bottom to top. For example, in C major, C is 1, E is 2, and G is 3.
I'll give an example to show how this works. Suppose your user has selected C major as the chord. You look up C major in the chords table; let's say its key (table key, not musical key) is 14. You then go to the ChordNotes table, and find that there are three records with a Chord key of 14; these records have 3, 5, and 7 in the respective note key fields. You then go and find the three records in the Notes table with keys 3, 5, and 7, and you have your chord.
Putting that example into SQL (I'll just make up names for the fields in your tables; you can use whatever field names and table names you want in your design):
SELECT C.CHORDNAME, N.NOTENAME FROM NOTES N
JOIN CHORDNOTES CN ON N.NOTEKEY = CN.NOTEKEY
JOIN CHORDS C ON C.CHORDKEY = CN.CHORDKEY
WHERE C.CHORDKEY = 14
ORDER BY CN.NOTEORDER
The result would look like this:
C Major C
C Major E
C Major G
That should give you a good base to start on. You'll need to work out how to get the key of the chord that the user selects from your UI (user interface), and how to display the result to the user. However, if you implement all this, you'll learn enough so that you'll have some idea of how to implement refinements that suggest themselves. Hope this helps, and good luck. :)