Link to home
Start Free TrialLog in
Avatar of Peter
PeterFlag for United States of America

asked on

Database Design

Consider the following database design concepts:  foreign key, relationship types (1:1, 1:M, M:N), connectivity, cardinality, strong entity, weak entity, strong (identifying) relationship, weak (non-identifying) relationship, optional participation, manual participation.

I understand what all these concepts are and what is said to be important about them.  But I just do not understand why they are important.  I presume it has something to do with the actual creation of the database, i.e., the DDL used to create the database objects.  For example, does it have something to do with the order of table creation?

Or, perhaps the question is better posed as this:  Once I have rendered a complete ERD (replete with all the concepts above), then how is the importance of all those concepts translated?

Oh wait, just thought of something.  Please refer to the embedded ERD.  How is the importance of the concepts translated?

User generated image
SOLUTION
Avatar of arnold
arnold
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Peter

ASKER

Okay...your replies are helpful, but I'm still confused.  Maybe I'm not asking the question right.  I think pcelba comes close when he says the "ERD uses some of the concepts mentioned but it still does not explain everything needed to... implement it.

I'm using SQL Server.  By implementation you mean creating the actual database with the data contained within the completed ERD (and the data dictionary), correct?  

So, during implementation, what am I doing that reflects the importance of understanding those concepts?

For example,
1.  The cardinality of Customers to Orders is 1:M.  Does that mean, that during implementation, I must create the customer table first?
2.  During implementation, how is the importance of participation reflected?  Why, during implementation, do I care what the participation is?

BTW - and this may be another clue - in response to pcelba again, I purposely did not mention normalization because I understand it apart from implementation.  That is, in my view, normalization is not implemented; it is a process completed before implementation.
1) yes.
Before creating an order, the customer must exist.

Normalization is a means by which you have one record to maintain that can be used in various ways.
Case in point, one usually will have a map city, state, zip. street names, etc.

In you db design, customer and vendor each gave city, state, zip
Normalization of those could reduce the storage needs of 32 char for city, 15 char for state with an int for each.


Db designers/architects pure approach deals with minimizing repetitive information in different columns/records.
The implementation of the DB is not done in a vacuum meaning, the DB U.S. Designed/payed out, and the app architect/developer/programmer has to conform....

There is a give and take between the competing groups. That happens before the User ease of use group gets involved.
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial