SqlServer database design

hi experts , I am new to SQL SERVER database design. work is assigned for a small project database designing. so, how should i proceed for to achieve this goal from starting to ending.

LVL 22
Tapan PattanaikSenior EngineerAsked:
Who is Participating?
Now that's a big one  --  Optimal, effective database design, end-to-end.  Small project databases or VLDB's (very large databases), there are some techniques that apply to both, always, and then there are practices that will vary based on the intended utilization of the database.  

I'm going to cut/paste this in here, because sometimes these pages aren't available unless you have logins.  It's a nice little post on sqlteam.com regarding database design and modeling fundamentals, by Brent Huscher:  http://www.sqlteam.com/article/database-design-and-modeling-fundamentals
Take a look at this and let me know how else I can help.

This article covers the basics of database design including normalization, relationships and cardinality. A great tutorial on database design.

Database design and the creation of an entity relationship diagram (also known as an "ERD" or data model) is an important yet sometimes overlooked part of the application development lifecycle. An accurate and up-to-date data model can serve as an important reference tool for DBAs, developers, and other members of a JAD (joint application development) team. The process of creating a data model helps the team uncover additional questions to ask of end users. Effective database design also allows the team to develop applications that perform well from the beginning. By building quality into the project, the team reduces the overall time it takes to complete the project, which in turn reduces project development costs. The central theme behind database design is to "measure twice, cut once".

Effective database designers will keep in mind the principles of normalization while they design a database. Normalization is a database design approach that seeks the following four objectives:

minimization of data redundancy,

minimization of data restructuring,

minimization of I/O by reduction of transaction sizes, and

enforcement of referential integrity.
The following concepts and techniques are important to keep in mind when designing an effective database:
An entity is a logical collection of things that are relevant to your database. The physical counterpart of an entity is a database table. Name your entities in singular form and in ALL CAPS. For example, an entity that contains data about your company's employees would be named EMPLOYEE.

An attribute is a descriptive or quantitative characteristic of an entity. The physical counterpart of an attribute is a database column (or field). Name your attributes in singular form with either Initial Capital Letters or in all lower case. For example, some attribute names for your EMPLOYEE entity might be: EmployeeId (or employee_id) and BirthDate (or birthdate).

A primary key is an attribute (or combination of attributes) that uniquely identify each instance of an entity. A primary key cannot be null and the value assigned to a primary key should not change over time. A primary key also needs to be efficient. For example, a primary key that is associated with an INTEGER datatype will be more efficient than one that is associated with a CHAR datatype. Primary keys should also be non-intelligent; that is, their values should be assigned arbitrarily without any hidden meaning. Sometimes none of the attributes of an entity are sufficient to meet the criteria of an effective primary key. In this case the database designer is best served by creating an "artificial" primary key.

A relationship is a logical link between two entities. A relationship represents a business rule and can be expressed as a verb phrase. Most relationships between entities are of the "one-to-many" type in which one instance of the parent entity relates to many instances of the child entity. For example, the relationship between EMPLOYEE and STORE_LOCATION would be represented as: one STORE_LOCATION (parent entity) employs many EMPLOYEEs (child entity).

The second type of relationship is the "many-to-many" relationship. In a "many-to-many" relationship, many instances of one entity relate to many instances of the other entity. "Many-to-many" relationships need to be resolved in order to avoid data redundancy. "Many-to-many" relationships may be resolved by creating an intermediate entity known as a cross-reference (or XREF) entity. The XREF entity is made up of the primary keys from both of the two original entities. Both of the two original entities become parent entities of the XREF entity. Thus, the "many-to-many" relationship becomes resolved as two "one-to-many" relationships. For example, the "many-to-many" relationship of (many) EMPLOYEEs are assigned (many) TASKs can be resolved by creating a new entity named EMPLOYEE_TASK. This resolves the "many-to-many" relationship by creating two separate "one-to-many" relationships. The two "one-to-many" relationships are EMPLOYEE (parent entity) is assigned EMPLOYEE_TASK (child entity) and TASK (parent entity) is assigned to EMPLOYEE_TASK (child entity).

A "foreign key" exists when the primary key of a parent entity exists in a child entity. A foreign key requires that values must be present in the parent entity before like values may be inserted in the child entity. The concept of maintaining foreign keys is known as "referential integrity".

Relationships between two entities may be classified as being either "identifying" or "non-identifying". Identifying relationships exist when the primary key of the parent entity is included in the primary key of the child entity. On the other hand, a non-identifying relationship exists when the primary key of the parent entity is included in the child entity but not as part of the child entity's primary key. In addition, non-identifying relationships may be further classified as being either "mandatory" or "non-mandatory". A mandatory non-identifying relationship exists when the value in the child table cannot be null. On the other hand, a non-mandatory non-identifying relationship exists when the value in the child table can be null.

Cardinality helps us further understand the nature of the relationship between the child entity and the parent entity. The cardinality of a relationship may be determined by asking the following question: "How many instances of the child entity relate to each instance of the parent entity?". There are four types of cardinality: (1.) One to zero or more (common cardinality), (2.) One to one or more (P cardinality), (3.) One to zero or one (Z cardinality), and (4.) One to exactly N (N cardinality).

In conclusion, effective database design can help the development team reduce overall development time and costs. Undertaking the process of database design and creating a data model helps the team better understand the user's requirements and thus enables them to build a system that is more reflective of the user's requirements and business rules. The act of performing database design is platform-independent so persons who use database systems other than SQL Server should also be able to benefit from these concepts.

Design for any DBMS begins with conceptual design. Are you familiar with how to design a relational database? If not, then probably best to get some assistance. Learning on the job may not be a good idea if your requirements are more than trivial. If you want to start learning here are two very good books:

Introduction to Database Systems by Chris Date

Information Modeling and Relational Databases by Terry Halpin
Here's another.  http://www.sql-server-performance.com/tips/database_design_p1.aspx
Both this and the previous assume you are going to design the database yourself, from the ground up.  

There are other ways to get it done, too.  Check out the 14-day free trial of ER/Studio from Embarcadero Tech.  Here's a good walk thru of the tool:
Cloud Class® Course: CompTIA Cloud+

The CompTIA Cloud+ Basic training course will teach you about cloud concepts and models, data storage, networking, and network infrastructure.

James MurrellProduct SpecialistCommented:
I would ask what is the project? this may help us get you what you need
If it is small project, just send me a requirements and perhaps I could send you a sql script or ER model.
well above are the generic suggestion, here is one more good article, worth to read. have a look


More help could be possible if you provide with some details.
Tapan PattanaikSenior EngineerAuthor Commented:
Thanks to all for your comments ,

hi zstapic, i will keep you in touch, send you the requirements very soon.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.