Docstoc

NHL Database Deliverable 2.docx

Document Sample
NHL Database Deliverable 2.docx Powered By Docstoc
					                                       Deliverable Two:

Step 3: Build and Validate Global Logical Data Model

3.1: Merge local logical models into global model:
This step is not necessary because we do not have multiple user views.
3.2 Validate global logic data model:
        All tables are normalized with no non-key attributes being dependent on only a portion of
the primary key. We accomplished this by keeping the majority of entities within their own
tables while also having many foreign keys within the Team table to show the most relevant
information while maintaining normalization. Three variable character keys were chosen so that
a user will know what name they represent without seeing the entire full name of the attribute.

3.3 Check for Future Growth:
        There is obviously the possibility for more teams, players, divisions, conferences,
owners, etc of entering the NHL and in turn our database. We have allowed to deletion and
creation of all these entities with ease while keeping our number and variable character ranges
large enough to accommodate any new entries. The only situation where we would need to make
changes to the fundamental design and configuration would be if a very large number of new
entries occurred in any entity type, such as 74 new NHL teams entering the league which is very
unlikely.

3.4 Draw Final Entity-Relationship Diagram:
       See hand-written report.




                            Microsoft Access Vs Oracle Discussion

        Using Microsoft Access was convenient to create our NHL database due to its user-
friendly interface. We already had established experience both with Access specifically as well
as other Microsoft products that are of similar design. This allowed for quick and easy
production of our entity relationships as well as data input. Forms, queries, and tables were
created without much trouble. Our database itself is fairly simple in nature due to concrete
relationships between our entities that are well-known structures in the National Hockey League.
The bulk of our efforts were deciding on what exactly would be an entity as opposed to an
attribute due to the convoluted nature of our database. In ideal circumstances, we would have
had less entities because concepts such as team arenas or team captains could also theoretically
be attributes of the entities team and player respectively. We chose to make these separate
entities so that our database would be a little more elaborate with more configurable information.
This decision did complicate some of the tables but were soon resolved with the implementation
of appropriate foreign keys.
        Microsoft Access is fairly cheap (as it is included in Microsoft Office, also increasing its
general availability and popularity) compared to Oracle (Oracle vs. Microsoft Access). Access is
chalked full of various wizards and GUI tools that guide the user through the various stages of
database design and configuration which again reinforces the ease of creating the appropriate
database (Microsoft Access). However, this ease of use comes at the cost of simplicity, as Access
is not as well designed for larger, more complex, multi-user databases compared to Oracle.
Finally, because all the data within an Access database is stored in a single file (Oracle vs.
Microsoft Access), it is not as useful for large quantities of data. Access seems to cater well to
smaller, less complicated databases such as our own compared to Oracle.
        Oracle is much more expensive software designed for larger databases such as those used
by larger organizations (Oracle Database). Its size and complexity render it difficult to create and
administer databases while simultaneously providing much more utility due to its many different
options during database design (Oracle vs. Microsoft Access). This utility exists to satisfy the
numerous intricate needs of multiple user databases that are integral components of enterprise
systems. Transaction control allows hundreds to thousands of users to be accessing the same data
simultaneously which Microsoft Access does not provide (Oracle vs. Microsoft Access).
However, these additional utility options slow down the database design process, rendering it
difficult to actually instruct the database to do what the designers and users require. Database
professionals would gain much more by using Oracle due to it being an advanced level DBMS
whereas a less proficient person attempting to create a database would have more to gain by
using the simpler Microsoft Access.
        Oracle demands less hardware requirements than Access in terms of memory and
processor usage. This is partially due to Access’ storage methods of keeping all the data in a
single file as well as the intensely graphical user interface. Oracle on the other hand makes much
more efficient use of storing the database information, again resulting in it being much more
ideal for larger databases with large quantities of data being stored. In terms of operating system
compatibility, Microsoft Access is used exclusively by the different versions of Windows
(Microsoft Access). This is obviously due to the fact that Microsoft sells Windows as an
operating system and would not want to allow their competitors the use of their database
management software. Oracle, on the other hand, is compatible with multiple operating systems
such as Windows, Solaris, and Linux (Oracle Database). This is advantageous because it can
penetrate markets in which Microsoft Access has no access.
        Industry users generally agree that Microsoft Access is better suited to smaller databases
being designed by relatively inexperienced people in terms of database design while Oracle is
better suited for larger databases being designed by savvy database designers (Microsoft Access
vs. Oracle). If our database had consisted of many more entities and more complicated
relationships, Oracle would have been a much more suitable DBMS to use. Because this was not
the case, Microsoft Access was very adept at satisfying both our needs as database designers as
well as any user needs that should be met by easily allowing us to implement our database and
create useful forms, queries, and reports that provided useful information to the user. Oracle, on
the other hand, took a fairly long time to figure out exactly how to get our database to do
precisely what we wanted even though the database itself was not altogether complicated.
                                            References

Microsoft Access. (2010, March 29). In Wikipedia, The Free Encyclopedia. Retrieved 23:09,
March 30, 2010, from
http://en.wikipedia.org/w/index.php?title=Microsoft_Access&oldid=352748169

Oracle Database. (2010, March 30). In Wikipedia, The Free Encyclopedia. Retrieved 23:10,
March 30, 2010, from
http://en.wikipedia.org/w/index.php?title=Oracle_Database&oldid=352962457

Oracle vs. Microsoft Access. (2010, March 30). In Search Oracle. Retrieved 23:12, March 30,
2010, from http://searchoracle.techtarget.com/answer/Oracle-vs-Microsoft-Access

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:7
posted:10/21/2011
language:English
pages:4