Stuck on ERD....I hate erd :( :(

fazmufc

New member
Local time
Today, 00:51
Joined
Apr 7, 2008
Messages
7
Hey all,

How are you doing?

Just wanted to ask for some help with this Erd Diagram and if anyone could really help me with it as i have come up really stuck here. I have to create a stock control system for company and i have done but the ERD was apparantly wrong and im a total novice when it comes to this :(

I need to create a ERD diagram and i have done but i got some feedback and been told its wrong. I wondered if anyone give me some of the helpful time and just show me what i can do to get it working.


The feedback i got was:

There may be some problems with your ERD. For example: Why are customers linked to just one product type? (Looking at your table descriptions, there isn't a link) Why is stock linked to one or more product types? (Looking at your table descriptions, it is the other way around). Stock and/or Products are not linked to Supplier Orders.
Your DFD is a bit simplistic...

I have attached a attachment, i be really greatful if someone could help me out with this, would really appreciate it as its doing my head in :(
 

Attachments

That looks like a nice way to waste valuable time to me.

If anything, what you need to do is use Excel or something to plan out the name of your tables, and what data you need to store in each.

Make a table name and put in all the fields for the data you need to store. Then check to see if anything is redundant. If so, figure out a way so that it isn't.

Once you get this part going, you will be able to see what you need to do design wise in order to keep your database normalized.

That Word document tells me nothing much regarding a database.
 
Sorry to waste your time mate, im just stuck on this and im a total novice so please forgive me :)

I have attached the data dictinonary to see if that may help in anyway as it lists what each table will have in terms of the fields.:)

I hope that can help in anyway or form, sorry if it cant.
 

Attachments

I'm just saying it looks like a waste of your time to do this is all.

But we all have our own ways of design...
 
The thing is i have to do it, its just something which i have messed up on earlier in my project. Its basically just something to show the progression but i know where you coming from mate.

Thanks for feedback though.

If anyone got any more advice please let me know really appreciate it
 
The thing is i have to do it, its just something which i have messed up on earlier in my project. Its basically just something to show the progression but i know where you coming from mate.

Thanks for feedback though.

If anyone got any more advice please let me know really appreciate it

I found a sample at http://webfuse.cqu.edu.au/Courses/win2001/COIT11166/Resources/Extra_Examples/ERD_Example_1/

Also this link may help.
http://r937.com/relational.html for normalization and design

ERD is not a waste of time. It can be a great help in defining the problem/business and can be an excellent communications tool. Especially useful if someone else is left to maintain/adjust the application. Like most documentation - it isn't for the developer per se but for those who come after and are expected to maintain/adjust an application and its data structures.
 
I'm just saying it looks like a waste of your time to do this is all.

But we all have our own ways of design...
ERD is a standard design technique and, while it might seem trivial here, it is particularly useful for more complex systems where you can't simply dive straight into tables.

Just wanted to ask for some help with this Erd Diagram and if anyone could really help me with it as i have come up really stuck here. I have to create a stock control system for company and i have done but the ERD was apparantly wrong and im a total novice when it comes to this :(
Smells more like a school assignment to me :cool:

It's difficult to offer much advice without the project specification. However, in a typical ordering system you would expect to see orders related to customers (take a look at the samples Access Northwind database). Quite often when you are think about relationships you will find that you can relate in more than one way. But usually one way is a stronger more logical and more direct relationship. Once the correct relationships are in place then other relationships can be traced though these relationship. So while you might think Customers are related to Products, in fact, "usually", Customer are related to Orders and Orders are related to Products.

Ask yourself what a supplier is related to. What really decides what supplier is used ? Personally I don't think it's the final transaction (by which I assume you mean a delivery).

You need to rethink how stock works imo. Don't forget that you've been asked to design a stock system.

Just another tip, I use to do my ERD's in MS Powerpoint because it's a much easier tool for creating diagrams like this. Then you can copy/paste into Word when it's done.

hth
Chris
 
ERD is a standard design technique and, while it might seem trivial here, it is particularly useful for more complex systems where you can't simply dive straight into tables.

Smells more like a school assignment to me :cool:
I aggree on both counts... ERDs can be immensly powerfull and usefull. I LOVE them to death, when made right... We have a system with 200 tables... how can you figure them all appart without something like an ERD??
Even with years working with this system I know the "core"/most important tables from memory, but... a lot of times you need more and you would be stuck.... but with the ERD, it is easy to find the relationships :)

I also agree with Stopher that you really need to step back and look at what you are really doing here.
A stock control system is there to "control stock", what happens to stock?? It goes in and out, but stock imho doesnt care anything about any freaking customers. That is what an Order system does...

FYI:
Your current ERD says something like:
One product can be sold to multiple customers, but a customer can only buy one product.

Now tell me doesnt that sound strange?
 
I aggree on both counts... ERDs can be immensly powerfull and usefull. I LOVE them to death, when made right... We have a system with 200 tables... how can you figure them all appart without something like an ERD??
Even with years working with this system I know the "core"/most important tables from memory, but... a lot of times you need more and you would be stuck.... but with the ERD, it is easy to find the relationships :)

I also agree with Stopher that you really need to step back and look at what you are really doing here.
A stock control system is there to "control stock", what happens to stock?? It goes in and out, but stock imho doesnt care anything about any freaking customers. That is what an Order system does...

FYI:
Your current ERD says something like:
One product can be sold to multiple customers, but a customer can only buy one product.

Now tell me doesnt that sound strange?

Further to my previous post, I agree with Stopher and namliam; it looks like a school assignment. That's why I suggested the example and the link to relational database design.

I have used ERD and modelling techniques for several database applications. ErWin was used mostly because of ease of use. The documentation provided was very complementary to data dictionary /repository holdings and data management practices.
 
Thanks for the advice lads.

It is a assignment but the strange thing is i got the system working to my requirements, but have had a check through and seems the ERD is my let down as it dont work correctly.

I am giving it a go, im not far of now i hope i can just get it fully functional.
 
happy hackers dont bother with ERD, or planning

just get it wrong quickly and start over
 
ERD's are a very handy thing for users who need to create reports or EIS as well. It is sure nice to know what the 'core components' are when you start with 300 +/- tables then DBA's with a case tool adds a couple hundred more :eek:
 
yes, i know really - its hard keeping track of data structures in anything other than a very small system.

seeing where everything is must help in normalising databases.

Although I've not done anything as big as you've just mentioned

------
out of interest, I recently built myself a little tool to store details of all tables/fields (typed) in a database - I update this as I add new fields to the development database. It then checks and reminds me which fields are missing from the TRUE BACKEND.
 

Users who are viewing this thread

Back
Top Bottom