|
|
|
|
This is the entity relation diagram for the piece of software I co-develop in a white collar. THERZ A LOT OF SHIT IN IT. ON? IN.
|
EmptyApocalypse
|
zomgwtfbbqsauce this is an intense ERD
Friday, October 6, 2006 12:47 PM
|
Lysander
|
who's the UML nerd
Friday, October 6, 2006 12:59 PM
|
elm3r
|
yay for ERD's.
Friday, October 6, 2006 8:23 PM
|
Okrbot23
|
does that fucntion like an "if this then this" scenario?
Friday, October 6, 2006 8:30 PM
|
JossaLION
|
It's a visual representation of how concepts (entities) are related to each other, no?
Friday, October 6, 2006 8:45 PM
|
Unmentionables
|
i just covered them in system analysis and design and that looks like some complicated shit thur
Friday, October 6, 2006 9:32 PM
|
elm3r
|
quote :
does that fucntion like an "if this then this" scenario? |
Nope. That would be a "flow chart", Oscar. Not an ERD.
ERD's are used for database designing. They show how tables inside of a database relate to each other.
Basically, this is a large database with many, many tables. And definitely a large ERD.
quote :
It's a visual representation of how concepts (entities) are related to each other, no? |
That would be more of a DFD (data flow diagram): that relates how general concepts relate to each other. ERD's are for actual relationships in the database.
OK KIDDIES! EXAMPLE TIME!!! COURTESY OF PROFESSOR elm3r
An example:
There is a database with 2 tables in it: Customer Information, and Order Information.
Customer Information has the following fields:
*customer_id
customer_name
customer_phone_number
customer_address
Order Information has the following fields:
*order_id
order_date
customer_id
order_total
The primary key of each table is marked with an asterik (*). These are unique identifiers that are not duplicated anywhere inside of the database. (Example: you, logically, wouldn't want 2 customers to have the same customer ID number. so, each one has their own, unique ID number.)
So, logically ask yourself which is more space-efficient: capturing customer data and storing that redundant data every single time they order, or store the customer data once, and just reference their customer number each time they order? Obviously, the second option is more efficient (both in storage space and processing time). So, an ERD would show how those two tables (Customer Information, and Order Information) are related. It would look like below:
Customer Information Order Information
---------------------- -----------------------
*customer_id >------| *order_id
customer_name | order_date
customer_phone_number |----------> customer_id
customer_address order_total
That, above, is an ERD. It shows that Customer Information and Order Information relate via the "customer_id" field. This also shows a "one-to-many" relationship between the tables (there's only 1 customer id number per order, but there can be many orders associated with a specific customer number).
Any questions? =)
[Edited by elm3r on 10/6/2006 11:56:53 PM. Reason for edit: w00pw00p]
Saturday, October 7, 2006 9:51 AM
|
Imperfect Clark
|
^ wtf
..so yeah, Joss, your description was fine. This is not a "true" ERD because it provides no details on the nature of the relationships between entities... just shows that which ones have constraints on each other (this is just a SQL Server 2000 diagram).
quote :
who's the UML nerd |
Bored coworker(s) (and not UML)
Friday, October 20, 2006 3:17 PM
|
elm3r
|
^wtf back at your "wtf". =)
Friday, October 20, 2006 3:44 PM
|
Lysander
|
one that i finished last night...not nearly as much shit on it, but the site stresses a level of interconnectivity
Wednesday, February 14, 2007 4:32 AM
|
Imperfect Clark
|
how modular of you
Friday, February 16, 2007 1:02 AM
|
|
|
|
