Hello Group,

I have a little designing problem. I am designing a database partially
from scratch and partially from a excelsheet model.

Now I try to explain what my problem is at the moment:
imagine you would program word for windows and word for mac. you can
say that there are parts in the windows word that aren't needed in the
mac word. i have a excelsheet with all modules in it (with a version
and revision). As you can imagine it is more important to build the GUI
(with editor) first and then build the grammar (and stuff like that),
that means, that you have many different programmversions ...

here are some typical entries:

"ID" "Modul" "version" "Programmversion"
"Project"
1 gui 1 alpha
windows, mac
2 save_as 1 beta
windows
3 save_as 2 beta
mac
4 example 1 alpha
mac
5 gui 2 alpha
windows

as you see there is the module save_as twice in the sheet (if there are
more programmversions and more projects there could be possible more
versions)

with database designing you can see, that the "project" gets me into
trouble. because one module can be in n programmversions (because it
gets changed a lot), but it doesn't mean that it is in the same project
(as you can see with modul gui) ...

i guess a table with

id modul version programmversion project
1 gui 1 alpha windows
1 gui 1 alpha mac
....
5 gui 2 alpha windows

should do the trick - and if you are searching for the programmversion
the gui is part of you can join a "modul"-table with the new table?!


i know this is really hard to understand, but if someone helped me with
an advice, that'll be great!!

christrier wrote:
I can't really help because I can't really understand what you think
the problem is - but I think you need to look at 'normalization'.

christrier wrote:
Bad idea. A database is NOT a spreadsheet!

Long before you get to tables, try to describe what it is you are
trying to model. There is a design approach that creates what is called
an Entity-Relationship Digram (ERD). So even before normalization that
strawberry mentioned, you identify what you want to store. The "What"
forms the entities. If you do a google search you should be able to
find some sites at colleges which are the course notes and they
describe this.

But basically you have something, an entity. Maybe it is a source code
package. Okay draw a box labelled code package. Inside the box you list
the attributes of the entity. So a code package has for example things
like: programming language, target platform, revision level, code
owner(original developer?), list of source file names, release
status(alpha, beta,...), and whatever defines a code package for you.
(NOTE: did you see an ID as a package attribute? neither did I. Most
likely with good design, you will not need it.) You might also have
other entities. maybe one for developers. The Developer entity might
have attributes like: name, date joined project, email address, and so
on. If a developer is going to work on a source file, it needs to be
checked out. But checking out a file is a relation between the package
entity and the developer entity. But in doing so you realize,
developers check out source files. So you split the package entity into
two: package and source.

so at this point you have three entities, developer, package, and
source code.
package and source form a hierarchy. every source file is contained in
a package, so source has an attribute of package name. Then checking
out source files means that you must decide if more than one developer
can work on a source file at a time. If only one is allowed, then you
can add a "checked out by developer name" attribute to the source
entity.

Again we are only drawing boxes at this point, Not defining tables. So
you have three boxes. you can drwa a line from package to source. this
shows the relationship between them. Using the names of the entities,
compose a sentence that describes this relation. You can usually write
it in both directions. A source file is contained in a package. A
package is composed of source files. label the lines with the verb part
of the sentence. so the line between the source box and the package box
has on each side of it:
is contained in
and
is composed of
Note: these lines of relation are often driven by what kinds of
questions you want to answer with the database, such as "who checked
out the saveas.cpp file?" They will involve matching attributes in the
related entities.

Now you proceed with normalization. This may involve creating more
entities to fit the design into normal form. When done the entities can
be mapped to tables in the database.


This was a too brief description, but some seacrhing in this group, and
on the web for Entity Relationship Diagrams and normalization should
bring you lots of resources.

HTH,
ed

Hi Ed,

well I have already designed the ER-Model. I did what you said and I
guess I have the same result.
My problem I had here was more complicated than the simple exampel i
could present to you. I am building a database application from scratch
and the only "rolemodel" how the people used to work was that
excel-sheet. I guess we all agree that excel is NO database and we all
see the limitations of excel, i.e. only one user at a time, etc.
Sometimes in the designing process you think about everything and you
have to figure out whether you are right or not. That is why I wrote to
this group. I wasn't sure what to do. But now I am back on track :-)

Thank you for your advice.

Greetings
Chris