Urban75 Home About Offline BrixtonBuzz Contact

Entity Relationship Diagrams

Onslow

More Ghetto than Netto
Fook Me.

I've been asked to make one of these ( out of the blue, no prior training, unrealistic deadline) for the recruitment process at work.

Ive done abit of research so know how they are supposed to be presented but dont really know were to begin:confused:

Anyone offer a helping hand?:)

I bet this is really straight forward to someone who knows how.:cool:
 
if you had no prior training and were given an unrealistic deadline you need to bring that up. It's not fair on you to ask you to do something you know nothing about. Yes, I know they try it on all the time but personally I wouldn't do it, especially if I had done some research and still felt lost.

Do you know anything about database design? (I'm assuming this is for a database)
 
can also depend on what the entities are that you have to show.

e.g. if its database tables its quite easy to use certain tools to reverse engineer the schema (i think even visio can do this)

howver if its something else there may well be tools dedicated to producing them

we use erwin in the main but thats purely for databse stuff.

you also NEED to understand what it is thats being mapped quite well too esp if the table names are like tbl_cdrmntpxm. If you dont have a scooby what the tables contain its fucking hard to draw an accurate diagram
 
I'v brought up those points, fell on deaf ears:(

Im just going to have to work through a tutorial.

I don't know that much about db design, but I do know they tend to be based on ERD's.
 
sue the bastards for constructive dismissal then ;)

i.e. stress brought on due to unrealistic expectations on you, no one listened to your concerns, you had to resign...
 
can also depend on what the entities are that you have to show.

e.g. if its database tables its quite easy to use certain tools to reverse engineer the schema (i think even visio can do this)

howver if its something else there may well be tools dedicated to producing them

Alot of the examples on the net seem to be about project management, but I cant seem to adjust the examples to fit our recruitment process!:eek:
 
so you are attempting to describe a process that has contributions from various diff depts?

tbh I would just use a cross functional flowchart. well easy to do and in visio there are some nice templates etc

like this

flowchart1.gif
 
Can you give a bit more detail (obviously avoiding direct references to the company) about what they want?

What will it be used for in the recruitment process?
 
Maybe they are testing me :confused:

testing you on what? are you a database designer, is that part of your job description? if it's not part of your job description then they can't really ask you to do it without giving you proper training.

e2a: sorry about the tone, but it really makes me angry when employers take the piss
 
owch

ERDs are an important element of a top down design for a relational database... but you kinda have to know what your doing.... as part of my degree we did ERDs but to be honest at least half of the class were still shit after 6 weeks

right at this moment i'm trying to fix a DB diagram ... i'm upgrading my exam system and properly declaring forign keys so i can cascade on delete
 
Can you give a bit more detail (obviously avoiding direct references to the company) about what they want?

What will it be used for in the recruitment process?

Hmm, I think they are looking to streamline the process, so want me to present in this way so they can anaylse it.

I actually know the process like the back of my hand ( from putting out a job ad, to actually getting someone in post)

But, I just dont know 'get' how i'd represent it in this god awful way:mad:
 
so you are attempting to describe a process that has contributions from various diff depts?

tbh I would just use a cross functional flowchart. well easy to do and in visio there are some nice templates etc

like this

flowchart1.gif

Thanks Pingu.

I've had to do one of these aswell, which was fine actually and quite enjoyable:confused:
 
just to echo what shippy has said we do erds for databases for a living and only about half of the people we have - all of whom are very very good at what they do - can produce a decent ERD. its a niche skill and if that is what you have been asked to do then it really is quite unfair.

we get paid a LOT of money to do them
 
testing you on what? are you a database designer, is that part of your job description? if it's not part of your job description then they can't really ask you to do it without giving you proper training.

e2a: sorry about the tone, but it really makes me angry when employers take the piss

No i'm not a db designer to be fair. Its kind of whats becoming the culture in this place, gradually increasing aggressive management style, pressure to get things done, without the resources or skills to do so etc:rolleyes:
 
Processes are normally mapped using entity state diagrams which are a bit simpler than relationship diagrams. They're pretty much common sense tbh. My advice would be to sketch up a flowchart, then convert it from steps to "things" (entities), then pick a format (UML should be a good one), and cobble it together.
 
j

we get paid a LOT of money to do them

Maybe it would be quite beneficial if i learnt then:eek:;)

I might have to pipe up with something soon. Or just do what I can and if they say anything let rip on how unreasonable it was in the first place.
 
just to echo what shippy has said we do erds for databases for a living and only about half of the people we have - all of whom are very very good at what they do - can produce a decent ERD. its a niche skill and if that is what you have been asked to do then it really is quite unfair.

we get paid a LOT of money to do them

sudden moment when the person drawing on the OHP realises that they have a many to many relationship

que lots of erasing
 
heh

or when they realise that what they are describing results in a cartesian join between tables that holds 230 million rows and 50 million rows

I btw am shit at ERDs
 
I asked on the other thread but this one seems busier. Do you know what level it needs to be normalised to at this stage.

You should prey for a level one or two.

I hate doing this wih a passion everything seems so backwards to me.


dave
 
I asked on the other thread but this one seems busier. Do you know what level it needs to be normalised to at this stage.

You should prey for a level one or two.

I hate doing this wih a passion everything seems so backwards to me.


dave

I was just reading your other reply.

It should be a very basic level ( well its going to have to be).

So I have an applicant, a recruiting manager, and a recruitment clerk.

An applicant can apply for one job, but a job can have many applicants. A recruiting manager can be recuiting to many jobs, but a job may only have one recruiting manager. A recruitment clerk can be sorting out many jobs, for many managers and many applicants! but each of those can only have one recruitment clerk.

Shit.the.bed
 
No i'm not a db designer to be fair. Its kind of whats becoming the culture in this place, gradually increasing aggressive management style, pressure to get things done, without the resources or skills to do so etc:rolleyes:

sounds familiar - maybe all managers nowadays go on courses on how to get the most out of employees for the least amount of money.

thing is, when you get people to do things they have no training for, it ends up costing a lot more in the long run, because things won't get done properly...

and as Pingu said, people get paid lots of money to do db design!
 
this may be of some help (its simplistic but ok)

http://www.sum-it.nl/cursus/dbdesign/english/intro040.php3

dude if we start on the normalised\denormalised data models and the arguments for and against each the OP is going to top themselves.

keep it simple is my advice

a REALLY cheaty way to do it btw would be to actually build the database in access and then use the database documenter to draw your relationship pictures for you
 
Back
Top Bottom