The database programmer is responsible for creating an organized and relevant tool.  He or she must display relevant and only relevant information as not to distract the user with useless clutter.  Attributes in a table should be related somehow to the table itself and to each other.  In other words, it is crucial for the designer to give the users the information they need and not to give them information they don’t.  User-friendliness is key!

Keeping attributes on track will also allow the programmer to link tables, which allows both users to retrieve and combine information from different tables.  If the programmer designs the database in this way, he or she can use relationships between tables to create alternate views of the information held in the database.

Database design is similar to the design of any instrument; it lays out the building blocks for the item to be built.  If the building blocks are not laid properly, the user will encounter problems.  Some problems may be insignificant such as a bit of irrelevant information, but some problems that have more to do with functionality have the potential to create more large-scale destruction.  As long as the programmer thoroughly considers the database design and tests for errors, a database has the potential to be an invaluable tool.

The purpose of functions is to return a value or a set of values, which the user defines. For example, a user may want to isolate certain records, which all share a similar attribute. For example, last name. A database user may want to find all of the records that belong to a certain person in the database. There are many ways a database programmer can do this, functions being one of them.

A large variety of user-written functions exist to perform different tasks. Loops may also be incorporated into functions, which provide programmers with the ability to make more complex functions. The step by step nature of the user written function gives the programmer the flexibility to create a function that performs its exact task.

]]> http://ryanjoyal125.wordpress.com/2009/04/01/plsql-user-written-functions/feed/ 0 ryanjoyal125 http://ryanjoyal125.wordpress.com/2009/03/27/blog-post-6-inner-and-outer-joins/ http://ryanjoyal125.wordpress.com/2009/03/27/blog-post-6-inner-and-outer-joins/#comments Fri, 27 Mar 2009 03:16:22 +0000 ryanjoyal125 http://ryanjoyal125.wordpress.com/?p=24 ]]> The idea of  different kinds of joins is very prevalent in the database world. A join is a tool that is used to merge rows from two separate tables in order to return specified rows. Such rows may be returned if common values exist in both tables, if rows meet certain join criteria, or if there are common values in common columns.

An inner join is the more traditional option when compared to an outer join. It only shows rows that meet criterion specified by the programmer. In other words, the inner join exists when tables are joined by a matching record. This connection allows database users to retrieve information from both tables.

An outer join, on the other hand, returns more than just matching rows, it returns unmatched attributes, thus allowing the user to retrieve information from different tables without an inner join. This may be helpful in the database design because if no matching records exist, things can be done to access other tables.

To mention a few more, the natural join, the cross join and the join on clause all add a nice compliment to the aforementioned joins. There are several types of joins with different parameters and which specialize in certain areas. Essentially, the programmer has their choice of retrieval options.

Built in functions allow programmers to change view of information and edit existing information.  Functions can be very powerful and modify a lot of data and they can also carry out minor changes to a database.  Below, I will identify 5 functions in SQL and briefly describe their purpose.

1. The “GROUP BY” function is very effective and combines the results of different functions into groups.  For example, if a user searches for customers who bought a particular item on a particular date, the group by function could be used to join these two functions into one table.

2. The “UCASE” function allows a user to change information from lower case to upper case.  This may be helpful in a manually entered field, as it will standardize the information.  People may input different cases and this function allows all the data to match.

3. The “LCASE” function does the exact opposite as the ucase function.  If the programmer wants to put the text of a certain segment in lower case, they should use the lcase function.  Again, this can be used to make uniform the data in varying fields.

4. The “ROUND” function is used in numeric fields and lets the programmer specify how many decimal points he or she would like in the database.  The programmer can select the number of decimals they desire.  This may be useful in a database with a lot of calculated fields.

5. The “NOW” function returns the current system date and time.  This function may be helpful in calculated fields if the programmer is trying to get a time reference.  Also, it may be helpful for something like an expense report or invoice because each purchase has their own date and time, but there is only one current date and time.  This function can allow users to see how long ago purchases were made in relation to the current time.

Once the conceptual framework is laid out, the designer must use relationships to assemble the concepts. She must go through each entity to make sure each has a uniquely identifying attribute. She must then match this new primary key with the foreign key of an entity with which he is trying to connect. Unlike the primary key, this foreign key does not have to contain a unique value.

Once the programmer has figured out the primary and foreign keys, she must make relationships between entities with information relevant to her conceptual diagram. She will use these joins to display the correct information in the database. Technically, the programmer may use Oracle to form these tables with primary and foreign keys. She may then set up the relationships between keys to present the desired information. This can be done using a wizard tool that walks the developer through all the steps of creating the table. If the programmer wants to do it the hard way, she can write the code to establish tables and relationships.

1. http://www.thecrumb.com/2008/12/02/developer-toolbox-oracle-sql-developer-data-modeling/
2. http://www.oracle.com/technology/products/database/sql_developer/files/Modeling.html
3. http://it.toolbox.com/blogs/oracle-guide/sql-developer-data-modeling-sod-25841
4. http://sueharper.blogspot.com/2008/10/first-early-adopter-oracle-sql.html

Below is a link that can compliment Data modeling users as it provides instruction on data mapping and other aspects of database programming.

http://philip.greenspun.com/sql/data-modeling.html

If more problems surface, these links can be very helpful in overcoming such obstacles. Also, many of the sites found above post updated information on news and current happenings in the Oracle and database fields, which can also aid in staying up-to-date with such a dynamic field.

There are several important characteristics to mention when explaining the purpose of different attributes. An attribute may be required or optional, which tells the user whether or not they have to input information into this field. A required attribute must contain a value and an optional may be left null if there is no information to be entered. The domain of an attribute gives the database user a choice of possible inputs that will be accepted into the database. For example, there may be a “type of computer” field in which the two input options are “PC” and “Mac.” Yet another feature of attributes is the users ability to use an identifier to identify the attribute, which uniquely identifies the entity, which it describes. For example, if an entity existed that provided information about students, a student id would be a good identifier instead of a first name because there are probably many students who share a first name.

Entities are connected using relationships. In other words, relationships represent different ways in which entities may be associated with one another and entities involved in relationships are called participants. Such relationships can usually be described using verbs. For example, a relationship may exist between a piece of bread and a toaster in which the toaster toasts the bread and the bread is toasted by the toaster. Both bread and toaster are participants and the relationship could be called “toasts” or “is toasted by” depending on which way you look at the relationship.

Weak Relationship – primary key of attribute ≠ primary key of second attribute.

Strong Relationship – primary key of attribute = primary key of second attribute.

Within the idea of participation two different types should be mentioned: Optional Participation and Mandatory Participation. Optional participation means simply that one entity does not require a corresponding entity, while mandatory participation does. Cardinality is another idea within database systems that provides more information on how entities associate with each other. Cardinality provides the minimum and maximum number of occurrences possible between certain entities. For example, a department of a company may have many managers, but a manager can only manage one department. In the case of this example, the cardinality from department to manager is zero to many because a department may have zero managers and may also have many. The cardinality from manager to department is zero to one because if a manager manages a department, he or she may only manage one.

The following link may provide very useful information. The link brings you to a database forum that addresses many relevant topics. This particular link will bring you directly to a page discussing entity relationships, but there are more topics: http://forums.databasejournal.com/showthread.php?t=49160

Some very useful information regarding entity relationships can be found at: http://www.umsl.edu/~sauterv/analysis/er/er_intro.html

Also, on the following link, good examples of entity relationships can be found: http://databases.about.com/cs/specificproducts/g/er.htm

On a broader scale, this link gives step-by-step instructions on creating a database: http://office.microsoft.com/en-us/visio/HP010181611033.aspx

I have also taken a class focusing on the diffusion of Web 2.0 programming throughout the internet.  In this course, we explored modern websites using Web 2.0 such as popfly.com, youtube.com, facebook.com, etc.  I also used popfly.com to create mashups used for practical problem solving.

In addition, last summer, I was employed by the IT department of a company called Alstom Powers Inc. for a summer internship.  Here I worked with databases in Lotus Notes and used a query/reporting tool called Hyperion.  My function at the company was mainly limited to producing customer reports, updating inventory changes, tracking parts, updating contracts, and developing optimization applications.