A few bold and daring members of the lifeBLUE team have decided to embark upon a great adventure…cleansing their bodies! Everyone knows that we, as a nation, are in the middle of a Food Revolution with recent thought provoking movie/books such as Food Inc and Fast Food Nation, and the LB is no different. Five noble team members have embarked upon this valiant quest filled with yummy shakes, delicious fruits and vegetables, and enough pills to choke a majority of small animals. On the first day of the cleanse we have suffered our first casualty (Note to Self: If you refuse to eat vegetables, fruits, brown rice, or drink protein shakes, this might not be a good diet for you). With that being said, the other four are still going strong with the exception that one person hasn’t started yet because they somehow don’t think they will be able to control themselves on an upcoming visit to New Orleans…good call.

How did the LB get started on the cleanse? Well truth be told one of our clients, Watters Creek Chiropractic, located not 500 yards down the road from our office has included overall health and wellness in their list of services as part of their effort to promote a healthy America. They are helping the LB along on their mission providing their expertise making the shakes tasty and likewise coming in to make a few shakes for the team. Thanks WCC!

All in all the 21 Day Cleanse is a good way to promote a different way of eating and likewise force us to commit to a system that doesn’t allow the bad food choices we are faced with each and every day. Hopefully we will be better citizens and web designer/developers when it is all said and done. If we’re not then we will at least decrease the gravitational pull on the earth by being 10% lighter. For more information on the 21 Day Cleanse and Watters Creek Chiropractic, visit their blog.

It’s no secret we love jQuery here at lifeBLUE. It’s made our life easier and our applications better. One task I find myself frequently doing is finding something nested within the tag or element I’m working with. For example.

<div id="iKnowAboutThis" >
    <div class="one" >One</div>
    <div class="two" >Two</div>
    <div class="iWantThis" >Three</div>
</div>

I know all about the div element with the id of “iKnowAboutThis”. I can get at that with a simple:

var iGotIt = $("#iKnowAboutThis");

I can use the jQuery object to do whatever I want. But what if I need to get at the element with the class “iWantThis” that is nested within “iKnowAboutThis”. If I have more than one on the page then I can’t just do this:

var iGotThis = $(".iWantThis");

If I do the above, I’ll get all of the elements with that class. All I want is the one nested within “iKnowAboutThis”. Fortunately, jQuery has a very powerful tool to help me.

By using the context option within the jQuery selector I am able to get at any nested item I want like this.

var iGotIt = $("#iKnowAboutThis");
var iWantThis = $(".iWantThis", iGotIt);

With that little snippet, my search for elements with the selector I specify stays within the context I set for it.

There you go, simple!

What’s in a niche? When I think of the term “niche” in the web industry, I immediately think, “Oh god, they’re all the same”.

• I hear “medical”, I think corporate and boxey,
• I hear “hotel”, I think text heavy, a decent looking banner image, and lots of forms,
• I hear “night club” I think huge photos, dark color schemes, with hardly any text,
• I hear “clothing retailer”, I think 2 column boring layout with cheesy stock photos,
• I hear “garage band”, I think dark, grunge backgrounds, with crazy fonts that you can’t read,
• I hear “daycare”, I think bright and pastel colors, with massive amounts of smiling children.

Does this mean that because you’re a marine biologist your website has to look a certain way, or if you’re a vacuum repair man you have a particular set of guidelines to follow when coming up with a look for your new website?

What comes to mind when you hear those terms? Every niche based industry seems to be so cliché. But it doesn’t have to be! Why not step outside the box? Rather then being the dreaded “this site looks just like all the others”, why not have the reaction of “Wow, I’ve never seen a candy store’s website look so awesome”. It’s up to you to start the trend that everyone else wants to then become.

So out of pure curiosity and an attempt to see how accurate I am, I’m gonna think up a few niche based industries and check out their sites, compare them, call them out on similarities, and see what differs as well. Here goes…

We’ll start fairly simple with “department store”.

You would think they all bought their template from the same place, right? The logo is in the top left, all three have a top row navigation, huge banner image, and columns of boxed ads. Let’s not forget the massive amounts of text links, everywhere! Not very original.

Next stop, let’s try “amusement park”.

Again, sensing a trend? Giant banner, navigation options along the top, banner ads in horizontal formation along bottom of site, and similar color schemes with blue backgrounds.

Moving on, “rock band”.

All three have a dark backgrounds, big band name written in grungy font and minimal text with the main focus on tour dates (understandably). And you gotta love the cheesy “backstreet boy”-type pose they all make. These guys are supposed to be hard core?

It’s lunch time, so I’m thinking “restaurant”.

We’ll try this two ways this time. Above, as you can see, are the less-thought-out ones. Upper left logo, understated banner area, we’ve now gone vertical with left navigation, and of course the huge banner image of food.

Now we’re talking! I have to give props to the above companies for turning their marketing efforts up a notch. It is a creative, outside the box, non-stereotypical, look at the appeal they have comparably. There are no similarities, they stand out above the crowd, and I’m gonna guess they are all currently on a waiting list for lunch. With websites this great looking, you’ll be fighting the crowds.

And lastly, I’m going with, “college”.

What we have here is a 3 column layout, school emblem in upper left, empty banner areas with a search box, left side navigation, and fairly low key color schemes.

So don’t become one in the same, let lifeBLUE help you break outside the box! Your website will thank us. You, of course, won’t have time to; because you’ll be too busy taking care of all your new customers.

The importance of Database Relations Normalization and its effects on efficiency.

“Schema Busters” is a multipart technical overview of Database Design elements that you can implement when designing and accessing your database implementation.  In this first section we will discuss the importance of a concept titled Normalization which aims to eliminate a number of undesirable attributes that a database relation may contain.  Initially we will discuss these undesirable attributes and then describe a number of popular methods, called Normalizations, to remove any undesirable attributes and convert an existing database relation into what is known as a Higher Normal Form Relation.  In each section we will also provide real world examples where such normalizations improve the quality of relations and query efficiency.

Undesirable #1: Non-atomic field values

Storing atomic (or indivisible) values in a field makes accessing data simpler and reduces redundancy.  Atomicity can be obtained by disallowing the direct storage of multiple values in a single attribute field.  That is, a single field contains at most a single element of the attribute domain associated with this field.  Take for example a CAR relation with a Color attribute.  Even though a single car may come in several colors, we would not want to store a list of colors in a single field since it makes accessing a single color element indirect and complicated (shown in figure 1).

CAR

Figure 1 – Non-atomic attribute Color

To resolve this issue we need to convert our CAR relation into what is called a First Normal Form relation.  There are different ways of achieving this, some more efficient than others.  Below is my recommended method:

• Remove the Color attribute from the CAR entity and place it into an associative table CAR_COLOR along with the primary key of CAR, Car_Id.

Pretty easy so far, right?  These two tables are now considered to be in First Normal Form.  We are now able to read in single car-to-color associations without the need of value parsing.

Undesirable #2: Non-Full Functional Dependency

Enforcing full functional dependency more accurately and properly associates relational data together.  For example, a table may have a composite primary key with different elements being functionally dependent on pieces of the composite key.  Full functional dependency separates data relations into intuitive dependency sets and allows for further database normalization.  Take for example the following CAR_SHOP, which refers to a shop that works on cars, relation and functional dependencies (denoted FD):

CAR_SHOP

• FD1: Car_Id, Shop_Id >> Price
• FD2: Car_Id >> Driver
• FD3: Shop_Id >> Owner

The functional dependencies describe relations between data.  FD1 simply states that for a given car at a given shop the price can be evaluated, FD2 states that a given car has a given driver, and FD3 states that a given shop has a given owner.  We can break up the CAR_SHOP entity to be simpler and more descriptive by performing the following manipulations:

•  Create a CAR entity that associates Car_Id and Driver.
• Create a SHOP entity that associates Shop_Id and Owner.
• Modify the CAR_SHOP entity that associates Car_Id, Shop_Id, and Price.

As you can see, this simply reflects the FDs described for our original CAR_SHOP entity.  These three new entities are considered to be in Second Normal Form.

Undesirable #3: Transitive Dependencies

Transitive dependencies exist when a non-key attribute of an entity is found on both the left and right-hand side of a known functional dependency.  This can lead to attributes being functionally dependent to non-key attributes.  Take for example a modified version of the CAR entity we described in the previous section:

CAR

Notice that we can derive the following functional dependency Car_Id >> DL_Number, SSN by the transitive property as shown below:

•  Car_Id >> Owner >> DL_Number, SSN

Since it is relatively safe to assume that a single Owner can have more than one car, we can easily see that having two entries in the CAR relation would generate repetitious data.  In order to simplify our entity we can take the following steps:

•  Modify the CAR entity and associates Car_Id, VIN, and Owner.
• Create an OWNER entity that associates Owner, DL_Number, and SSN.

We can verify that these manipulations are valid by double checking that the original functional dependencies still hold on our new relations, CAR and OWNER.  FD1 now holds on the modified CAR entity and FD2 holds strictly on the OWNER entity.

Conclusion (for now)

While there are more normalizations we can consider, several have limited practicality in real-world environments and can be made unnecessary if a database is designed carefully.  I say this not to belittle their importance, but to recognize the matter of pertinence in our discussion.  If your projects are requiring you to perform additional normalizations, you may consider picking up Fundamentals of Database Systems by Elmasri & Navanthe or another database schema textbook and doing some independent studies.  Hopefully by now you have gained a general understanding of the importance of database relation normalization and how it can improve your database schema.  Look for my next entry in this series where we will discuss additional database schema concepts and practices.

.blogtable { width:100%; border:solid 1px #333333; color:White; } .blogtable th { background-color:#555555; color:White; } .blogtable td { background-color:#aaaaaa; color:White; padding:5px; }