EmptyApocalypse
144 Photos
|
zomgwtfbbqsauce this is an intense ERD
10/6/2006 7:47:54 AM
|
Lysander
1 Photos
|
who's the UML nerd
10/6/2006 7:59:41 AM
|
elm3r
41 Photos
|
yay for ERD's.
10/6/2006 3:23:33 PM
|
Okrbot23
226 Photos
|
does that fucntion like an "if this then this" scenario?
10/6/2006 3:30:17 PM
|
browneyes
7 Photos
|
It's a visual representation of how concepts (entities) are related to each other, no?
10/6/2006 3:45:36 PM
|
Unmentionables
133 Photos
|
i just covered them in system analysis and design and that looks like some complicated shit thur
10/6/2006 4:32:02 PM
|
elm3r
41 Photos
|
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]
10/7/2006 4:51:23 AM
|
Imperfect Clark
116 Photos
|
^ 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)
10/20/2006 10:17:18 AM
|
elm3r
41 Photos
|
^wtf back at your "wtf". =)
10/20/2006 10:44:52 AM
|
Lysander
1 Photos
|
one that i finished last night...not nearly as much shit on it, but the site stresses a level of interconnectivity
2/13/2007 11:32:11 PM
|
Imperfect Clark
116 Photos
|
how modular of you
2/15/2007 8:02:32 PM
|
.