1st Database, Artists and Images to 10 products per image (1 Viewer)

[RetailSource]

Hi! Beginning our 1st database, as I have realized that I just need to learn more than excel. I'm just starting to realize and understand normalization of data, I thought I would have to make an artist table/form. Have users complete artist information create button to start entering image information for the works of the artist and thought it would need to create a new table, but I believe that is incorrect. There should be an 1 image table with all of the different artists images in one table, just each image is associated to the different artist. So hopefully that is right, so here is the basic concept. Please let me know if I'm forming the structure of the database correctly.

Artist Table - form fields are the table fields.
- Artist Form - Where user enters basic Artist info (Names, Address information, Licensed, OpenDomain, email, Bio, Profile Pic, TotalImages-want this to count number of images created per artist, NewArtist button-create new artist record, AddImage button-want this to go and start the add new image form and link with the artist.)

Image Table - Form fields are the table fields
- Image Form - Where the database user enters the individual image information for the artist. (Image Title, Long Description, Orientation-Verti/Hori dropdown, Equator-check box, Prime Meridian-check box,DPI-#,Attachment-Image file, ArtistNameFK-foreign Key.)

Product Table
- Product Form - Where the user enters any new product types we will turn the images into (ProductType, ProductDescription)

Media Table
-Media Form - Where user enters any new possible media that we can possibly use to compare costs of media we use to make art of images. (ProductSKU-SKu of media product, MediaName-Name of media, Cost,Width, Length)

Sizes Table
- Sizes of the finished product that we will be able to make, at the moment 10 size variations (Height, Width)

We want the user to be able to enter in Artist information then their image information and save into the database.
Once this information is stored, then we want to be able to export the artist image information into 10 different products for 1 artist image in it's 10 different size/product styles.
Then when we know how to make these different sizes/product styles to export into our inventory database excel import format, and then also into our 5 other retailers import excel formats.
Then record if and how many have been uploaded into their systems, or show a percentage bar for each artist of how many of their images have been uploaded and live.
BUT, we I am not at the last export/extrapolating data. Still at just normalizing and building the structure. Any and all advice would be extremely helpful, as after this I will be doing a general product one as well. I currently have gone through the Lynda.com essential access tutorial and will be using any and all video tutorials available to me.

I don't know how to attach the database or show it to anyone, could use some help on that as well.

Thanks everyone for the help. I'm hoping to build this in a few weeks. I know I can learn a lot and complete a build of this.

 

[The_Doc_Man]

Here are a couple of rules to consider:

Old Programmer's Rule #1: If you can't do it on paper, you can't do it in Access. Meaning, if you don't have a good diagram or layout of your data such that you can answer questions about where you are going to look to get the data you need, you don't have enough up-front work done yet. You need to lay out a road map of what you need to do for each action you want to perform.

Old Programmer's Rule #2: Access won't tell you anything you didn't tell it first. Meaning, Access knows NOTHING about ANYTHING (except the functions for data manipulation). You are the source of all info about art, artists, products, media, etc. If you want Access to tell you something, you have to assure that it has a way of finding what you wanted. For example, if you wanted to know the artist's eye color in the personal description, you have to include a slot for that information as well as a way to report it in an appropriate manner. This is actually a corollary to the old "Garbage In, Garbage Out" saying - Nothing In, Nothing Out.

Implementing Rule #2 may SOMETIMES require you to work backwards from desired output to some midnight caffeine-overloaded session of "How the hell are we going to get this information into the database so we can report it?"

You need to design what you want your database to do because without a road map, you don't know your destination. If you don't know your destination, how will you know you have reached it?

Now, your table structures: You seem to have done some analysis, so I'll offer this simple advice: Tails don't wag dogs. Meaning, if your business process says "X" then your database must also say "X" or else you have allowed the database to drive the business.

Therefore, part of your answer to Rule #1 is to have a list of business rules that define data transformations, translations, movement, whatever. You are in essence building a model of your business so whatever you do in the real world has to be logically implemented in your application. DON'T SKIMP on data flow analysis. It will make the difference between resounding success and abject failure.

 

[RetailSource]

Thanks for the input! We diagrammed out our desired roadpath today. And I am writing out each of our tables. Then we are going from there! I'll let you know how it goes.