object-oriented database systems are designed to...
TRANSCRIPT
Data Modelling, Data Visualisation and the Third Dimension
V 5.0Dermot Duncan
Department of Information Technology
National University Of Ireland, Galway
September, 2010
i
AbstractThe application of both 3D modelling and data visualisation techniques to current data
modelling methodologies will both simplify the design of complex databases and
improve the usability and navigability of complex data models. By using advances in 3D
modelling and the representation of 3D objects, the clarity, ease of use and overall model
can be dramatically improved. As it is not restricted to single dimensions, a much larger
set of data can be displayed clearly, in a much smaller space. Using modern data
visualization techniques, data models can be made much more interactive and navigable
making them a lot more accessible and usable to a broader spectrum of users. This
research proposes a new 3D data modelling approach which incorporates some data
visualisation techniques and develops an interactive Flash tool to implement this
approach. Experiments are conducted on this tool by a varied set of users to provide a
broader spectrum of results.
ii
iii
AcknowledgementsI would first like to acknowledge the support of my supervisor, Colm O’Riordan. He was extremely generous with both his time and patience and offered continued guidance and encouragement throughout my research.
I’d also like to thank all my testers who put up with the initial hiccups on the testing site and generously donated both their time and energy to help me complete my experiments.
Lastly I’d like to thank everyone who helped proof read this document for all their advice and continued patience throughout each version of the thesis.
iv
Contents
Abstract................................................................................................................................iiAcknowledgements............................................................................................................iv1. Introduction..................................................................................................................1
1.1. Research Overview..............................................................................................21.2. Scope....................................................................................................................31.3. Significance of the study.....................................................................................41.4. Research Questions & Hypothesis.......................................................................51.5. Methodology........................................................................................................61.6. Case Study...........................................................................................................71.7. Success Criteria...................................................................................................81.8. Thesis Layout.......................................................................................................9
2. Literature Review......................................................................................................112.1. Introduction........................................................................................................112.2. Database Design Overview................................................................................11
2.2.1. Modelling...................................................................................................122.2.2. Entities & Keys..........................................................................................122.2.3. Mapping & Relationships..........................................................................132.2.4. Cardinality.................................................................................................152.2.5. Normalization............................................................................................16
2.3. Modern Modelling.............................................................................................182.3.1. Relational Database...................................................................................182.3.2. Entity Relationship Model.........................................................................192.3.3. Object Model.............................................................................................202.3.4. Differences between relational and object-orientated models...................21
2.4. Human Computer Interaction............................................................................222.4.1. Computer Characteristics...........................................................................222.4.2. Human Factors...........................................................................................232.4.3. Information Visualization..........................................................................242.4.4. FishEye / Lens Visualization.....................................................................25
2.5. Current 3D Modelling Approaches...................................................................282.5.1. 3D Modelling Processes............................................................................282.5.2. PaperVision3D...........................................................................................31
2.6. Modern Representation of Data.........................................................................322.6.1. Information Retrieval & Digital Libraries.................................................322.6.2. Kartoo........................................................................................................332.6.3. Intelligent User Interfaces..........................................................................34
2.7. Conclusion.........................................................................................................353. System Design and Implementation..........................................................................37
3.1. Bubble Modelling..............................................................................................373.2. System Design...................................................................................................40
3.2.1. Architecture...............................................................................................403.2.1.1. Language................................................................................................413.2.1.2. Framework.............................................................................................413.2.1.3. GUI........................................................................................................443.2.1.4. Middle Tier............................................................................................49
v
3.2.1.5. Database.................................................................................................553.2.2. Prototype Design.......................................................................................563.2.2.1. Initialization...........................................................................................563.2.2.2. Entity Construction................................................................................583.2.2.3. Navigation..............................................................................................603.2.2.4. Schema & Entity Creation.....................................................................613.2.2.5. Schema Retrieval...................................................................................65
3.3. System Implementation.....................................................................................673.3.1. Entity Creation...........................................................................................673.3.2. Create Relationships..................................................................................693.3.3. Schema Deletion, Retrieval & Save..........................................................703.3.4. Navigation..................................................................................................74
4. Experimental Design and Setup.................................................................................784.1. Websites.............................................................................................................784.2. Experimental Design.........................................................................................794.3. User Guide.........................................................................................................804.4. Feedback Questions...........................................................................................804.5. Case Study.........................................................................................................824.6. Experiment 1 – Navigation................................................................................824.7. Experiment 2 – Create New Schema.................................................................844.8. Experiment 3 – Update Existing Schema..........................................................854.9. Experiment 4 – Find Table Information............................................................86
5. Results........................................................................................................................885.1. Experiment 1 – Getting Started.........................................................................89
5.1.1. User Feedback...........................................................................................905.1.2. Trends & Exceptions.................................................................................925.1.3. Interpretation of Results............................................................................94
5.2. Experiment 2 – Create New Schema.................................................................945.2.1. User Feedback...........................................................................................945.2.2. Trends & Exceptions.................................................................................975.2.3. Interpretation of Results............................................................................99
5.3. Experiment 3 – Update Existing Schema........................................................1005.3.1. User Feedback.........................................................................................1005.3.2. Trends & Exceptions...............................................................................1025.3.3. Interpretation of Results..........................................................................104
5.4. Experiment 4 – Find Table Information..........................................................1055.4.1. User Feedback.........................................................................................1065.4.2. Trends & Exceptions...............................................................................1085.4.3. Interpretation of Results..........................................................................109
6. Conclusions and Future Work.................................................................................1116.1. Conclusions......................................................................................................1116.2. Future Work.....................................................................................................113
References........................................................................................................................115List of Figures..................................................................................................................117Technologies & External Resources................................................................................118
vi
1. IntroductionThis thesis is concerned with exploring advances in data visualization techniques and
seeing what advantages, if any, can be obtained from applying these techniques to data
modelling approaches.
In the modern world with all the technological advances in the web, along with the
emergence of technical power houses such as Google, there is an abundance of
information freely available. One of the challenges with having so much information and
data available is how to represent and display this data so it is useful?
Similar issues arise in the visualisation of large databases. How can a database containing
hundreds or thousands of tables be modelled or displayed so as to give an accurate
picture of the database?
Information retrieval on the web was revolutionized with the emergence of Google and
their searching and filtering algorithms. Similarly back in 1976, the modelling of
databases was revolutionized by Dr Chen with his entity relationship model.
Both of these approaches still face issues though. This has triggered a lot of advances in
the field of information visualization. On the web there are alternative search engines
emerging such as KartOO which groups data in easily navigable maps. There are a lot of
interactive charts such as goggle charts, loaded with functionality for displaying and
efficiently using massive volumes of data.
Data modelling seems to have fallen behind these advances. However, data modelling has
similar goals to information retrieval systems such as Google and KartOO and
information visualization systems such as interactive charts. One goal of data modelling
is to accurately display large volumes of data so it can be used effectively. There is no
reason why techniques such as the fish eye lens technique used in interactive charts,
1
cannot also be utilized in modelling a database to create a more visual and navigable
model.
This study is concerned with evaluating the improvements that can be obtained from
incorporating data visualization and 3D rendering techniques into the process of data
modelling. Improvement is a broad term. By redesigning the data modelling methodology
and developing a tool which incorporates some modern data visualization functionality,
this study aims to measure improvements in the simplicity of the data modelling process
as well as the readability and usability of the data models created.
1.1. Research Overview
Object-oriented database systems are designed to meet the requirements of advanced
database applications. These requirements can constantly change and evolve over time
and so must be managed consistently across all levels of abstraction [1]
- The database level
- The database schema level
- The data model level
This thesis deals primarily with the data model layer. It proposes to evaluate current data
modelling techniques and practices, design a 3-D alternative to the classic flat tree-view
menu approach and develop an interface to implement this new approach.
The complexity of databases tends to grow over time as tables are added, removed,
modified and enhanced. Analyzing these databases is a very time-consuming process and
usually requires a high-level of both expertise and familiarity with the schema.
This thesis will evaluate both the advantages and limitations of current 2D data modelling
methodologies. Based on these findings it will propose expanding these methodologies to
incorporate a new 3D data modelling approach which will include advances in the
2
information visualization field. We hypothesise that improving upon the current 2D
methodology will simplify both the design and upkeep of large and complex databases.
An integral part of this research will be to develop a graphically and functionally rich tool
to implement this new 3D modelling approach. The tool will allow exploration of
complex databases by creating graphical displays of tables for a user to navigate through.
1.2. Scope
This thesis will be limited to investigating database data modelling and will be composed
of three main phases
1. Evaluating current data modelling techniques
The first phase of this project will be to research current data modelling techniques and
outline the key advantages and limitations of these approaches. This phase will also be
concerned with researching advances in both 3D modelling approaches and the field of
data visualization which has parallels to this study
.
2. Designing a new 3D modelling approach to database modelling
This phase of the project will design a new 3D modelling methodology using the research
obtained in phase one. It will explore the advantages of 3D modelling over the current
flat approach. The rules and outline of the new methodology will be defined in this phase
including representing tables, elements, attributes and relationships in 3D.
3. Developing a RIA Interface for the new 3D modelling approach
The third phase of this project will be to design and develop a functionally and visually
rich interface to implement the 3D modelling approach designed in phase two. The tool
will allow the creation of new database schemas along with the ability to manipulate
schemas created by the tool. Based on time constraints this could be enhanced to also
read in existing schemas.
3
1.3. Significance of the study
This study aims to provide an alternative approach to current data modelling
methodologies. This is an area which has evolved significantly over the past number of
years. From Chen’s proposal of entity relationship models, to normalization to UML
modelling, database modelling techniques have been constantly changing. Substantial
improvements in the modelling process have been made with the introduction of software
packages such as IBMs Rational Rose and Microsoft’s Visio packages. However these all
have the same fundamental flaw. There will always be limitations to how much data can
be displayed on a screen at one time. The larger and more complicated a database gets,
the greater amount of real estate the model will take up. The more relationships and
complexity added to the database, the more cluttered and over populated the model
becomes. This is a problem which has plagued other fields including both information
retrieval and data visualization systems.
The ability to more intuitively model the data would greatly improve its usability for
users. By incorporating some simple techniques such as 3D spatial navigation or
Fig 1.1
4
3D modelling and more modern data visualization techniques offer a solution to this
problem. It has the advantage of an extra dimension so a much larger set of data can be
displayed clearly, in a much smaller space. Multiple relationships on single entities could
be displayed much more cleanly and effectively. Also, utilizing data visualization
advances in similar fields would allow simpler navigation and analysis of larger and
complex schemas and greatly simplify the modelling process. The advantage of this to
any corporation would be time saved in both the analysis and design of complex
schemas.
Fig 1.2
1.4. Research Questions & Hypothesis
This section briefly introduces the research questions this study aims to answer along
with the hypothesis this research will prove or disprove.
What are the limitations of current data modelling techniques?
To improve the data modelling process we first need to ascertain the exact limitations of
this process.
What would the advantages be to adopting a 3D approach to data modelling?
Once we’ve discovered the limitations of the current modelling approaches we will
investigate how these can be improved by adopting a 3D approach
How would modern data visualization techniques improve and simplify data
modelling?
5
Building on the above, we aim to discover how the use of modern data visualization
techniques could improve the usability of data models, making them more accessible to a
broader audience.
Is it possible to represent a complex database with a simple and easily navigable
model?
We will perform an analysis of the affect of adopting the new modelling technique with
the data visualization functionality available in the prototype has on a complex model and
whether it can simplify a complex design.
The thesis hypothesizes that current data modelling techniques create complex models to
represent complex databases. With been restricted to a 2D realm models take up a much
greater area than they need to. These models are not easily navigable and require a certain
level of both expertise and familiarity with the database been modelled to be useful to a
user. By evolving the models into the 3D realm and incorporating some modern data
visualization techniques and functionality into a new modelling tool, complex database
can be depicted by simple models. The user will be easily able to explore these models,
simplifying any updates, enhancements or manipulation of the model.
1.5. Methodology
This research involves the practical implementation of a 3D modelling tool. As outlined
in the scope this involves three key phases which will be developed using an agile design
approach. Each of these phases has a dependency on the previous phase; however each
phase will be broken into use cases and built up over iterations.
In phase 1, an ethnographic research approach would be useful in evaluating current
modelling techniques. According to Spradley (1979), ethnography is "the work of
describing a culture". He emphasizes, however, that "rather than studying people,
ethnography means learning from people [2]”. There is a traditional culture of data
modelling today which uses a flat 2D tree-view menu to display database schemas.
6
Understanding the reasons behind this main-stream trend as well as why data
visualization techniques in similar fields have not been made in the data modelling field
will be key to the success of this research. As well as using Ethnographic studies to
ascertain the reasons behind the popularity of the 2D tree-view modelling approach, it
could also be used to outline the key rules and requirements a new 3D approach would
have to adhere to.
We will use a case study to investigate the evolution of current database modelling
methodologies. This allows greater freedom to create a hypothesis. The case study used is
described briefly in the next section. The end product of this phase will be the design and
implementation rules of the new 3D methodology. This will then be used to help prove or
disprove the hypothesis. In the experiments, which are discussed in greater detail in
Section 5, a comparison between the new and old methodologies will be conducted to
ascertain the advantages, if any, offered by the 3D approach.
An agile approach will be used for the development phase of this research. The outcome
of this phase will be a prototype to allow 3D exploration of databases. This will both
implement the new methodology created in Phase 2 above, as well as providing some
data visualization techniques to navigate through the new model. The first task to this
phase will be prioritizing the functionality which is essential for the success of the
project.
1.6. Case Study
As the thesis moves through development iterations, this case study will be expanded
upon but the following is the basis for the case study. Design a relational database to
support a modern payroll system.
7
The system must contain some key elements. All an employees details should be
accessible by the system. There are different types of employees. Some are on an hourly
salary and so qualify for overtime while others are on an annual salary and cannot earn
overtime. Employees on an annual salary are eligible for a bonus once a year which is a
percentage of their annual wage. Employees can receive their pay by either a check or
straight into their bank account through direct deposit.
This system must be able to highlight where money is been spent. To achieve this, a
record must be kept of the projects an employee bills their hours to. Each project is
composed of multiple tasks and the system will be expected to support this granularity.
Deductions are taken from each pay check an employee receives. This can include taxes,
health insurance and other miscellaneous deductions. A record needs to be kept of the
deduction amount from each pay check as well as the total yearly deductions.
This case study was chosen as it is a very adjustable model. It can start off relatively
simple but can grow into a very complex system. This will allow the new methodology
put forward by this thesis to be tested on multiple levels from creating a new model to
enhancing a relatively straight forward model to support a much more complex system.
The case study is discussed in more detail in Chapters 3 and 4.
1.7. Success Criteria
This study will be deemed successful should the steps outlined in the scope be met:
- A sufficient investigation into current data modelling practices is conducted with both
advantages and limitations documented. Data visualization techniques which have
parallels to this research are identified and researched.
- A workable 3D data modelling methodology has been successfully designed and
documented.
8
- A functionally rich tool has been developed to implement the aforementioned 3D
design. The design of this should also be documented
- An academic thesis document is prepared which adheres to MSc requirements and
consolidates the findings from each of the above 3 phases
1.8. Thesis Layout
As described in the scope above this thesis is structured so as to gradually approach the
goal of a completely functional 3D data modelling tool. First, relevant literature is
examined to order to establish and clarify the concepts and approaches which will be
used. Topics covered will include database design and data modelling. Some history as
well as the key concepts of both will be investigated and briefly introduced. The focus
will then move on to 3D representation and visualization of data. A brief review of
current approaches will be conducted, highlighting their advantages and limitations. Prior
to this, there will be some discussion on the HCI aspects of representing these models.
Next we will move into our design Chapter. This will outline the design and
implementation of both the new 3D methodology as well as the data visualization tool
used to implement this methodology. Justification and explanation of design decisions
and approaches will be documented.
We will then move into our experimental design section. This will outline the design of
the experiments used in our examination of the hypothesis and justify why they were
chosen. The next Chapter provides a detailed description of the results and findings of the
experiments and whether the hypothesis was proved or disproved.
The conclusion will evaluate the progress and success of the project and what
contribution it might provide to other research. A broad explanation of any future work
will also be provided.
9
10
2. Literature Review
2.1. Introduction
This section begins with taking a look at a broad overview of modern database design
followed by a brief exploration of some current data modelling approaches. The
importance of HCI in modern systems is then briefly examined with an emphasis on data
visualization. This is followed by a broad overview of modern 3D modelling techniques
and a brief review of current approaches in existing tools. Finally there is a section briefly
describing some other approaches to information visualisation which have parallels to
this thesis.
2.2. Database Design Overview
A modern database is composed of three separate design components [27].
1. Conceptual Design
This is the initial step in database design. It is independent to both hardware and software
and is primarily used to define user requirements for the system by identifying
relationships and dependencies within the system [27].
2. Logical Design
This stage logically sorts the data into tables using the relationships and dependencies
identified during the conceptual design. This involves mapping the data to a specific data
representation model. It is independent of any physical DBMS system [27].
3. Physical Design
The system’s hardware and software specifications are defined in this phase [27].
This overview will be concentrating on the first two stages of database design. It will go
through some of the more common techniques used in modern data modelling
techniques. These include how the data is decomposed and sorted into smaller and more
coherent clusters of data and how these clusters are related back to one another.
11
2.2.1. Modelling
A data model is a descriptive representation of the data a business requires to accomplish
its mission. Data modelling involves the exploration of data-oriented structures to
identify data attributes, relationships between the data and dependencies amongst the
data. The goal of data modelling is to create an abstract model to represent data elements
and their relationships in a structured consistent model. This model
- characterizes the behaviour of the system
- identifies relationships and dependencies amongst the data
- organizes the data based on these relationships and dependencies
- identifies data sharing possibilities
- reduces redundant and duplicate data entry
A good data model is not ambiguous, is easy to read and accurately depicts the data it is
representing in its simplest form. It minimises redundant and duplicate data and is
flexible enough to be expanded upon in the future.
2.2.2. Entities & Keys
An entity is a single person, place, or thing about which data can be stored. There are
multiple types of entities in databases which include:
Strong (Independent) entities: Strong entities are not reliant on any other entities and so
can exist independently. For example, a course can be taken by zero or more students.
Weak (Dependent) entities: Dependent entities can only exist if there is a related instance
of some other entity. For example, a student must register for one or more courses.
Intersection or Associative entities: Intersection entities are used to split a many-to-many
relationship into multiple one-to-many relationships. For example, the relationship
between a student and a course would be many to many as a student can attend multiple
courses and each course can be attended by multiple students. If we introduced another
12
table called timetable, there would now be a many-to-one relationship between student
and timetable and a one-to-many relationship between timetable and courses.
Subordinate entities: Subordinate entities are entities in a table which can be decomposed
into subsets. For example, an employee table contains basic information on an employee
such as employee number, address and phone number. However there are two types of
employees – full-time paid monthly with no overtime and part-time paid hourly with
overtime. Both are subordinate entities which share some common attributes in the
employee table but can be split into subsets with their unique attributes. Full time
employees would have an attribute for their monthly wage while part-time employees
could have attributes for their hourly rate and another for their hours worked.
Databases depend upon keys to store, sort and compare records. Keys are also used to
identify relationships between different tables and are an essential part of database
normalization.
Primary Keys: The identification of primary keys is one of the most important decisions
when designing a database. Primary keys are attributes or sets of attributes which can be
used to uniquely identify each record in a table. For example, student number in a table
with no more than one record per student.
Foreign Keys: Foreign keys are fields in a table used to reference a primary key of
another table. They are primarily used to cross-reference and identify relationships to
other tables. For, example course code could be the primary key in a course table. This
could be set as a foreign key in a student table to show which course a student is taking.
2.2.3. Mapping & Relationships
One of the most important steps in data modelling, no matter which approach is taken, is
identifying relationships and dependencies amongst the data been modelled. “A
relationship is a logical connection between two or more entities” [4]. Usually, a verb or
13
preposition that connects two entities can be described as a relationship. See Fig 2.1.
Relationships can be characterised by the following:
Degree: the degree of a relationship defines the number of entities in the relationship. Is
an entity related only to one other entity or is it related to multiple entities? It is possible
to have N-ary relationships for any value of N but in practical scenarios it is usually
limited to the following three
Unary
Binary
Ternary
Multiplicity defines the relationship between two entities.
One-to-One Relationship
Two entities are considered to be in a 1:1 relationship if not more than one instance of
one entity exists for one instance of the other entity. For example, when describing a
conventional marriage a husband and wife would have a 1:1 relationship as each
husband only has one wife and each wife only has one husband.
One-to-Many Relationship
Two entities are considered to be in a 1:M relationship if zero or more instances of
one entity exist for every instance of the other entity. The many can be displayed in
multiple ways – two popular notations are an “M” and a crows foot “<”.
For example, a mother and her children would have a 1:M relationship as a mother
can have zero or more children but each child can only have one mother.
Many-to-Many Relationship
Two entities are considered to be in an M:M relationship if for every instance of
either entity there are zero or more instances of the other entity. For example, a
student can attend multiple courses and each course can be attended by multiple
students.
14
Direction defines the direction of the relationship. In a one-to-many relationship this
shows which one of the entities has zero or more instances for each instance of the other
entity.
Fig 2.1
2.2.4. Cardinality
Cardinality refers to the values of rows contained in an individual table in the database. [5]
This is a major aspect of relational data modelling used to identify relationships.
There are three main types of cardinality
High Data Cardinality: A data column which has high data cardinality would contain
values which are very uncommon or unique. It is not likely that any two rows would
contain the same data in such a column. Primary key columns would be considered to
have high data cardinality. [5]
Normal Data Cardinality: A data column with normal data cardinality would not contain
unique values. However, the values would be some-what uncommon so there would still
be a high range of values in such a column. [5]
Low Data Cardinality: A data column with low data cardinality would contain rows with
very similar data or a low range of data [5]. For example, a Boolean column where all the
values are true or false.
15
2.2.5. Normalization
Normalization is a technique used to efficiently organise data in a database. This helps to
simplify the design of the database, reduce redundancy and ensures data dependencies are
accurate and make sense resulting in an optimum database design. The “normal forms”
are a linear progression of rules with each rule improving the efficiency and redundancy
of the design [3]. These rules range from un-normalized form up to Fifth Normal Form.
However, it is usually sufficient to only go up to Third Normal Form.
First Normal Form (1NF): The goal of 1NF is to remove duplicate data from the same
tables. Each group of related data is split into separate tables and each table identifies a
unique column or set of columns to be its primary key. All rows in the table must have
the same number of columns and each non-key attribute must be functionally dependent
upon the primary key. [3]
Second Normal Form (2NF): As a pre-requisite 2NF must meet all the requirements of
1NF. Any table with a single column primary key is already in 2NF. Partial dependencies
(an attribute which is only determined by part of the primary key) are then identified and
subsets of tables are split out into smaller tables. Foreign keys are identified in these
smaller tables to relate them back to their previous tables. [3]
Third Normal Form (3NF): As a pre-requisite 3NF must meet all the requirements of
2NF. 3NF looks to identify two problems – derived data and transitive dependencies.
These occur when non-key attributes are dependent on other non-key attributes. This
usually means that an undiscovered relation is still embedded within the table. Each table
is scanned and columns which are not dependant on the primary key in that table are
grouped together and split into smaller tables. [3]
There are certain limitations with the third normal form as originally defined which led to
the definition of multiple higher normal forms. Boyce-Codd Normal Form (BCNF) is an
extension of 3NF and a database is said to be in BCNF if every determinant is a candidate
16
key [23]. For example, the following table where supplierId is the primary key,
supplierName is unique and partID and quantity are just regular attributes, is in 3NF
{supplierID, supplierName, partID, quantity}
However, supplierID and supplierName are determinants; one determines the other.
Splitting the table up as follows would put it in BCNF:
{suppliedID, supplierName}
{suppliedID, partID, quantity}
Fourth and Fifth Normal Forms apply to situations involving many-to-many
relationships. To achieve 4NF each independent many-to-many relationship needs to be
represented through its own cross-reference table. [29] For example in a college a student
and lecturer could have a many-to-many relationship and a lecturer and course could
have a many-to-many relationship. The following table would be in violation of 4NF
{studentID, lecturerID, courseID}
The table would need to be split up as follows to achieve 4NF
{studentID, lecturerID}
{lecturerID, courseID}
{studentID, courseID}
A 5NF table should have only candidate keys and its primary key should consist of only a
single column. A table in 5NF cannot be reconstructed from several tables containing
fewer attributes. The drawback to these higher normal forms is the complexity it
introduces due to the size of the joins they required. [29]
17
2.3. Modern Modelling
2.3.1. Relational Database
The relational database model was conceived by E. F. Codd in 1969. It is founded on
mathematical theory and logic. The basic idea behind the relational database model is that
a database can be manipulated using non-procedural operations that return an organized
set of tables. Basically, all data in a relational database is stored in tables. All data
manipulation is performed at the table level rather than at the individual data level. [3]
The following are some of the main concepts associated with relational databases:
- Every table must have a primary key to uniquely identify tuples.
- All primary key columns must contain values. Null primary key columns are
not allowed. This is known as entity integrity.
- There are three types of relationships in relational databases. See section 2.2.3
- Databases are optimized through the process of normalization.
- Any foreign keys defined must exactly match the primary key they are related
to in another table. This is known as referential integrity.
Some advantages of relational databases are:
- More efficient data manipulation.
- Database behaviour is predictable, cutting down on errors.
- Database is self-documenting.
- Updates and enhancements to the database schema are normally easy to
implement.
Some limitations of the relational model are:
- Logical and physical modelling will always have some dependencies on one
another.
- Relationships have no explicit representation. They are identified from
information not contained in the relational model.
18
- It uses conflicting philosophies to object orientated design. For example, the
relational model does not use inheritance.
2.3.2. Entity Relationship Model
Modern data modelling was revolutionized in 1976 when Dr Peter Chen wrote his
brilliant paper “The Entity-Relationship Model--Toward a Unified View of Data” [28]. In
his paper, Dr Chen introduced the Entity/Relationship modelling approach which is still
widely used today. The purpose of ER modelling is to create an accurate interpretation of
the real world in a database. The database is portrayed as a graphical representation of the
logical relationships between entities.
Over the years, there have been multiple spin-offs and variations created of Chen’s
Entity/Relationship modelling approach such as the Richard Barker notation used by the
Oracle Corporation. However, although these differ on how the data is displayed (slightly
different notation, different objects used to depict entities and attributes) they follow the
same underlying structure. To simplify this overview, this thesis will concentrate on the
Chen and Barker Notations.
In Barker notation, entities are represented by round cornered rectangles with their
names, as well as their attributes, inside the rectangle. Relationships are shown as lines
with cardinality [1]. This is very different to Chen notation in which relationships are
displayed in a 2D diamond. As the Chen notation was the first type of ER model there
have been improvements and changes in subsequent techniques. For example, Barker
splits many-to-many relationships with intersection entities, using a diamond to describe
relationships removes the need for intersection entities as the relationship itself plays the
role of an intersection entity [1]. Whether this is more efficient is a matter of opinion.
Another major difference between Barker and Chen is that Barker uses prepositions to
describe relationships whereas Chen uses verbs.
19
There are numerous advantages to ER modelling.
- Allows visual representation of data.
- They are easy to understand so can be explained to a non-technical user.
- Can be easily mapped to a relational database.
But there are also disadvantages
- The more entities in a system the more room required to model them out.
- Does not clearly show that an occurrence of a sub-type is an occurrence of a
super-type. However specialisations, generalisations and categories are
supported in EER modelling.
2.3.3. Object Model
Object Modelling was created to model out an object oriented software system. Unlike
Entity-Relationship Modelling, instead of using entities, object modelling models “object
classes” and instead of relationships, it uses associations. These though, are very similar
to ER modelling. Where it differs is its ability to describe inter-relationship constraints.
Similar to ER Modelling, there are multiple approaches and spin-offs of object
modelling. As UML (Unified Modelling Language) is becoming the dominant object
modelling technique, to simplify this overview this thesis will concentrate on the UML
model. UML is a standardized modelling language used in software engineering. Similar
to ER models it describes a set of graphical notation rules to create visual models of
databases. It includes multiple types of diagrams besides object diagrams such as use-
case and sequence diagrams. [1]
In UML, an object is described as a rectangle with three divisions
- Top which contains the Object Name
- Middle which contains a list of the objects attributes
- Bottom which can contain behaviour descriptions
UML introduces the concept of stereotypes which is used to enhance the standard
notation. These can be used to enhance object, attribute and association definitions.
20
Unlike ER modelling, associations or relationships are described by characters rather than
graphically. Associations can be depicted by either a triangle and a verb with the triangle
showing direction and the verb describing the association or, similar to Barker notation,
relationship names or roles can be used to describe the association. [1]
Advantages of object modelling include
- Allows any inter-association relationships to be represented in the model.
- Attributes/Entities are described in much greater detail than in other modelling
techniques.
- Makes use of flags to add extra description of business rules.
Disadvantages of object modelling include
- Due to the multitude of relationships which can be depicted in the model, it
can become quite complicated and so would require a level of expertise to
read.
- The more objects in the model, the more space that is required by the model.
2.3.4. Differences between relational and object-orientated models
Although similar, there are a number of differences between the relational and object-
orientated models. These have been mentioned in the previous few sections but will now
be looked at in greater detail.
OO models are based on proven software engineering principles and normally use objects
with both data and behaviour. Relational models meanwhile are based on proven
mathematical principals and are normally concerned with the storing and manipulation of
data only. [24]
Relational models tend to use logical references. Relationships are identified by logical
keys – a foreign key in one table links directly to a corresponding primary key in a
related table. In the OO model, relationships are identified by internal system identifiers
21
rather than user-defined attributes. Normally keys are not modelled on class diagrams in
OO models. [24]
OO models usually define various constructors which are used to support complex object
structures. Inheritance is also supported by OO models allowing new objects to be
defined from existing objects. Relational models do not tend to make use of constructors
nor support OO properties such as inheritance but do enforce entity and referential
integrity. [24] The constraints enforced by OO systems vary.
These differences between the relational and OO models are known as the “Object-
Relational Impedance Mismatch”.
2.4. Human Computer Interaction
Human Computer Interaction is the study of interaction between computers and humans
(users who use computers). Because of the wide range of topics which HCI covers, it is
hard to characterize an exact definition. However, SIGCHI (The Association for
Computing Machinery Special Interest Group on Computer Human Interaction) define it
as "a discipline concerned with the design, evaluation and implementation of interactive
computing systems for human use and with the study of major phenomena surrounding
them [6]“. The goal of HCI is to make computers more user friendly. It aims to achieve
this by enhancing computers to take into consideration the human cognitive model when
performing operations. The idea being that incorporating the human cognitive model into
their calculations will improve the computer’s processing of the user’s task.
2.4.1. Computer Characteristics
HCI is concerned with computer characteristics which are related to communication with
people. This includes:
22
Ergonomics and usability: “Ergonomics derives from two Greek words: ergon, meaning
work, and nomoi, meaning natural laws, to create a word that means the science of work
and a person’s relationship to that work [10]”. From the perspective of computers,
ergonomics deals with reducing health risks such as repetitive strain disorder.
Dialog design: Dialog design is concerned with defining techniques and interfaces to
interact with humans. This can include dialog screens for input and output such as
warning or error messages and interaction styles like pop-up screens.
Visualization: Information visualization is concerned with representing complex abstract
data in a form understandable to humans by creating visual representations of the data.
HCI also includes basic principles that affect the ability to learn such as general look and
feel, standardization and interoperability.
2.4.2. Human Factors
Incorporating human factors into the design of information technologies is critical for the
success of these technologies. [7] The following are some main human factors which
should be taken into consideration when designing a computer system:
Human information processing characterises how humans process information. This takes
into consideration characteristics such as memory, motor skills, learning and skill ability
and problem-solving skills which will vary between different users. [7]
Aspects of language such as syntax, specialized alphabets, semantics and pragmatics as
well as conversational interaction are investigated to maximise communication between
the system and the user. [7]
23
Ergonomics: This generally looks at anthropometric and physiological characteristics of
people, their relationship to their workplace and their environment. It can include an
investigation into the arrangement of displays and controls, disabilities and cognitive and
sensory limits. [7]
Not taking human factors into consideration can result in:
- a lack of human productivity and ineffective work practices
- a decrease in worker efficiency
- missing system functionality
- user dissatisfaction
- increased costs
2.4.3. Information Visualization
Information Visualization is "the visual representation of large-scale collections of non-
numerical information, such as files and lines of code in software systems [8]". The
bandwidth of the human vision is the largest of all the senses. Information visualization
takes advantage of this by creating interactive visual representations of abstract data. This
data does not necessarily have a physical counterpart, an example been, results showing
how many hits a particular webpage had received. Information visualization can
transform and represent this data in a form that allows and encourages human interaction.
Complex abstract data can be translated into a visualization of the data which can be
changed and manipulated by users as they work on it. Users can navigate through this
visualization and have the ability to interact with it as well as modify and enhance it. This
greatly simplifies the data allowing it to be analyzed by exploration rather than pure
mathematical reasoning. By modifying the data visualization, users can develop a better
understanding of the relationships and structures in the data quicker and with less
specialized expertise. [8]
24
Data visualization techniques are diverse and can vary in both complexity and use. Some
common techniques include:
- Charts
- Graphs
- Mathematical Diagrams such as Venn Diagrams
- Cluster Diagrams
- Tree Maps
- Geographical Maps
- Scaling data
- Layering of data
- 3D representation of data
- Volume Rendering
Information Visualization is like writing. Similar to good writing, good graphical
displays of data efficiently communicate ideas with clarity and precision, leaving little
room for misinterpretation or confusion. But similar to bad writing, bad graphical
displays can distort or obscure data, making it confusing to understand and open to
misinterpretation by the user. [9]
2.4.4. FishEye / Lens Visualization
The FishEye concept was developed to support the visual exploration of cluttered graph
layouts. Large graphs, representing large volumes of data, tend to become both dense and
cluttered and so much harder to read. This approach offers a range of fisheye lenses to
interactively navigate through these clustered graphs. [22]
25
Fig 2.2
The fisheye lens magnifies a selected area, and slowly zooms out of surrounding areas.
The further away from the selected focal point the less magnified the area is as seen
above in Fig 2.2. [22]
The local edge lens helps to distinguish a small number of relationships from a highly
cluttered space by highlighting only the relationships of selected nodes. [22] See Fig 2.3
Fig 2.3
26
Some node relationships can be hard to see as the nodes can be spaced far apart in
relation to the chart or graph. The bring neighbours lens brings related nodes closer
together so relationships are easier to distinguish as seen in Fig 2.4. [22]
Fig 2.4
Composite lens is a combination of the above 3 lenses to utilize the strengths of each and
minimize their weaknesses. Firstly the bring neighbours lens is applied to bring all related
issuers into a specified area. The fisheye lens is then applied to magnify this area and
space out the selected nodes and the local edge lens is then applied to highlight the
relationships between the selected nodes. [22] This can be seen in Fig 2.5
27
Fig 2.5
The fisheye lens approach is one technique for improving the visualization of large
volumes of data and is the type of functionality which will be useful in the development
deliverable of this research.
2.5. Current 3D Modelling Approaches
2.5.1. 3D Modelling Processes
- Polygonal Modelling
An example of polygonal modelling can be seen in Fig 2.8. It is an approach for
modelling objects by approximating their surfaces using different shapes or polygons. A
vertex is a line between two points. A polygon is a creation of three or more sides. The
basic premise is that an object is generated from a “mesh” of polygons which are
connected together by shared vertices. Because polygonal models are made up of
multiple faces, they are easy to edit and animate which makes them well suited to
architectural or low-detail models.
28
Fig 2.6
- NURBS
“Non-Uniform Rational B-Splines, are mathematical representations of 3-D geometry
that can accurately describe any shape from a simple 2-D line, circle, arc, or curve to the
most complex 3-D organic free-form surface or solid [15]”. NURBS uses mathematical
equations and algorithms to form precise representations of freeform surfaces. Further
reading on the mathematical process involved can be found in [16]. NURBS provide
smooth surfaces making them ideal for organic modelling. An example can be seen in Fig
2.9.
Fig 2.7
29
- Spline Modelling
Spline or patch modelling is an efficient alternative to polygon modelling which uses
multiple lines called splines to describe curves. Similar to polygon modelling a “mesh” is
created from intersecting splines. The areas formed between intersecting splines in a
mesh are known as patches. These meshes can be lathed or extruded to create 3D
geometry. [17] Since organic forms are naturally curved, spline modelling is suited to
organic modelling as can be seen in Fig 2.10.
Fig 2.8
- Primitives Modelling
Complex models are built up using multiple primitive objects such as cubes and spheres.
Models can be very quickly built up and because they are based on primitive objects, are
very precise. See Fig 2.11. This type of modelling is better suited to technical models.
Fig 2.9
30
- Sculpt Modelling
There are two different methods of Sculpt Modelling [30]:
1. Displacement: Takes an existing model and changes pixel positions storing the new
locations in an image map.
2. Volumetric: Operates in a similar manner to displacement but uses voxels rather than
pixels. Where pixels define 2D image data in a bitmap, voxels refer to volume
elements and as a result do not suffer from polygon stretching.
An example of sculpt modelling is shown in Fig 2.12. Sculpt Modelling allows for
creative exploration of models and is so best suited to artistic modelling such as 3D
games and virtual worlds.
Fig 2.10
2.5.2. PaperVision3D
PaperVision3D is a web based open source 3D engine for the Flash platform which has
the ability to create a real world like spatial effect on animations. It gives designers the
ability to create interactive environments which provide an impressive visual experience
to users by giving them the ability to simulate three dimensional environments using 2D
computer graphics. See Fig 2.13 below for an example. 3D engines like PaperVision3D
can be very processor intensive and so performance can be poor for large systems.
31
Fig 2.11
2.6. Modern Representation of Data
2.6.1. Information Retrieval & Digital Libraries
Information Retrieval (IR) is the science of searching for information, within documents,
databases and the World Wide Web. A user enters a query (for example some key words
into a search engine), and the results of their query are algorithmically ranked with the
top ranking objects been returned to the user. Kartoo, an example of a modern and noval
information retrieval system is discussed in the next section in greater detail.
A digital library is a library in which collections are stored in digital formats which are
accessible by computers. [19] There are a lot of advantages to digital libraries
- Searching capabilities are significantly increased with the use of computers
- Promotes information sharing
- Information is always available and easy to maintain
These concepts have parallels with the subject of this thesis. The success of this thesis
will be founded on the ease of use of the tool. An important aspect of this ease of use is
for a user to be confidently able to save a data model and be easily able to retrieve the
same model to study or update.
32
Similar to all aspects of technology, IR and Digital Libraries are constantly changing and
improving. It is important to be aware of these changes when deciding on the quickest
and safest method to save and store information required for the tool to be a success.
2.6.2.Kartoo
Kartoo is a new kind of information retrieval approach which provides users with an
array of search solutions. The French based company bases their idea on the fact that
people use maps to find their way around large cities so why not take a similar approach
to searching through data. [21]
As soon as you launch a search, Kartoo analyses your request, questions the most
relevant search engines and selects the best sites, displaying results on topic-based maps
showing the relation among different subjects (Fig 2.14).
Although not directly related to the primary topic of this thesis of database modelling, the
Kartoo system is an example of the advances in the domain of representing information
and results. Earlier search engines assume certain behaviours from users and so provide a
general and standard approach to searching. In recent years there has been a lot of
emphasis placed on different types of intelligence and how different users perceive and
use data differently. Alternative search engines such as Kartoo allow users to facilitate
their search based on their type of intelligence. This is a design aspect which will need to
be considered with the technical part of this thesis.
33
Fig 2.12
2.6.3. Intelligent User Interfaces
The idea of intelligent user interfaces was founded in 1988 when a group of researchers
met up in California for a workshop titled “Architectures for Intelligent Interfaces”.
Intelligent user interfaces is an intersection of Artificial Intelligence and Human-
Computer Interaction. [18]
With the advent of artificial intelligence technology, which gives computer systems the
ability to reason as well as decision making abilities, computer applications increase in
complexity. In direct correlation the complexity and criticality of HCI also increases.
Traditional user interfaces are not able to cope with this complexity while effectively
reflecting the semantics of the user’s tasks and problem domain.
34
Intelligent User Interfaces explore concepts such as
- Personalization
Personalization allows the user to personalize the application to their tastes and
save these settings to a database or some other digital library to be retrieved
whenever the user uses the system.
- Adaptation
Based on how a specific user makes use of an application, the IUI should adapt to
minimize number of errors as well as optimize efficiency and effectiveness.
Similar to the fields of IR and Digital Libraries, IUI is a constantly evolving field which
also has parallels with the subject of this thesis. One of the criteria for success of this
project is to develop a user-friendly data modelling tool. Aspects of IUI, such as those
discussed above, describe functionality which will be essential and expected of the tool.
Users expect a certain level of intelligence from modern computer applications. For this
tool to be deemed a success, users will need to find it intuitive and easy to use so
recognizing parallels with IUI is an important part of the success of this project.
2.7. Conclusion
Although the techniques described in Section 2.3 do a good job of creating a clear and
complete model of databases, they are limited. For one, they are static representations of
the data which concentrate on a single point of time. They are not easily manipulated and
by only using one dimension they are always going to be limited for space. As a database
grows to support a larger system, its data model will become larger and more complex.
Been restricted to two dimensions it is going to take up more space so less data will be
able to be viewed concurrently and models can become more cluttered and so less
intuitive.
The limitations of the current static, single dimension techniques can be enhanced and
improved upon. By taking advantage of the extra dimension available with 3D modelling,
more data can be displayed more cleanly in a smaller area. Entities, attributes and
35
relationships can be depicted more simply in 3D. Utilizing some of the data visualization
techniques discussed earlier the models will be easily manipulated and more importantly
easily navigable by the user. John Tucay says it best: “One great virtue of good graphical
representation is that it can serve to display clearly and effectively a message carried by
quantities whose calculation or observation is far from simple [11]”. The database been
modelled might be far from simple but that is no reason why the models depicting them
shouldn't be simple.
36
3. System Design and ImplementationThis chapter outlines the design and implementation of the new 3D design methodology
and the GUI prototype developed to implement this new methodology. The first section
describes the new design methodology, called Bubble Modelling, which was created to
support the new 3D approach to data modelling. The case study used to test the new
system is then briefly examined and discussed. Leading on from this, the following
section investigates the design of the prototype GUI. Finally the implementation of the
new system is examined and documented.
3.1. Bubble Modelling
One deliverable of this thesis was to create a modelling methodology to use with the
prototype. The methodology created was Bubble Modelling. The main idea behind
bubble modelling is that a data model can be represented by a multi-tier of bubbles. The
reason bubbles were chosen to build the model is that they are perfectly symmetrical in
3D space. As a result, the user experience of navigating through a set of spherical tables
is a lot better than if other 3D objects, such as a cube, were used.
Rather than having a traditional 2D table containing all the table information, a table is
represented by a bubble. The only information displayed by default is the table name as
seen in Fig 3.1.
Fig 3.1
37
Bubbles are scattered around a preset 3D space which allows more tables to be displayed
at one time than in a traditional 2D setting. To further reduce the clutter of the model,
relationships are hidden by default. Relationships between tables are displayed by
moving the cursor over the table as seen in Fig 3.2
Fig 3.2
As mentioned above, attributes and keys are not shown by default. The user can choose
to display the members of a table by clicking on the bubble. The original solution
proposed for Bubble Modelling attached a member attribute to each of the sub bubbles
which make up a bubble. For small tables with few members this approach worked well.
However, larger tables were not as successful. Due to their large number of attributes,
larger tables became very hard to read when attributes were shown. Unless the user
zoomed in on the table, it was very difficult to distinguish one attribute from another.
Zooming in to a certain level made finding relationships between tables impossible. It
was thus decided that this approach was impractical. As a result it was decided to use a
hybrid approach to showing attributes. Tables would still be represented by bubbles
which allowed a greater number of tables to be displayed intuitively and efficiently in a
much smaller space. But attributes are displayed in a 2D representation of the table, as
shown in Fig 3.3.
38
Fig 3.3
Bubble modelling adheres to the relational database design rules outlined in Section 2.2.
However, as this is a proof of concept methodology and due to time constraints, not all of
the design rules were implemented in the design. This is discussed in further detail in the
future work section of Chapter 6. The main concepts incorporated into this first version
of the prototype were centred on relationships and keys.
As mentioned above, the original design was proven to be impractical for large tables.
Originally it had been planned to denote keys with different colour bubbles. Primary keys
would be red and foreign keys would be blue. The updated design operates similarly.
Now the background colour of primary keys is red while foreign keys have a blue
background in the 2D representation of the model. This can be seen in Fig 3.3.
Multiplicity originally was going to be displayed by having nothing for a one relationship
and a double bubble or the appearance of a bubble surrounded by another bubble to
denote a many relationship. Since this original design was scrapped it was decided to
show the relationship types on the 2D interpretation of the bubble. This partly stuck to the
original design and single relationships are still denoted by nothing. Many relationships
were surrounded by a think yellow box as seen in Fig 3.3. So many-to-many relationships
would show two attributes surrounded by yellow boxes connected. One-to-many
relationships would show one attribute surrounded by a yellow box connected to another
attribute with a regular border. One-to-one relationships would show two attributes with
regular borders connected.
39
From a usability point of view, it is generally better not to tie any one piece of
functionality or information down to a particular colour. This is so the tool supports users
who are colour blind. However, it was decided that this was the most efficient and
intuitive way to denote keys and relationships as it took up no space and could be easily
explained to and understood by new users. To work around the usability issue,
personalization will be added to the tool so that users can define which colours they wish
to use. An optional key could be displayed to denote what each colour refers to.
3.2. System Design
The prototype used to explore and test ideas put forward in this research forms the
development backbone of the work. The aim of the prototype is to help prove the
hypothesis that 3D modelling and data visualization techniques will both simplify and
improve the data modelling process. To achieve this, firstly the prototype needs to have
the base functionality to map a static 2D data model into a virtual 3D space. Secondly, it
will require some key data visualization functionality to maximize the usability of the
model. Thirdly, but most importantly, it needs to be designed so that it is intuitive and
easy to use by a varied range of users.
The first sub section below describes the technical design of the prototype. Following on
from this, the remaining sub sections step through some of the key use cases in the use of
the prototype.
3.2.1. Architecture
This section goes into detail on the technical design of the prototype. It describes design
attributes such as technologies and design patterns, and discusses why certain decisions
were made and certain technologies chosen over others.
40
3.2.1.1. Language
As discussed in Section 2.5 there are a number of 3D modelling tools available today.
However, this prototype required a certain level of animation as well which was not
feasible in these tools. Speed and performance coupled with a lot of complexity were all
important aspects of the prototype. C++, the traditional language for creating high speed
games was evaluated but it didn’t have the necessary 3D rendering capabilities required
by the prototype.
Flash, although a good choice for animation is historically more processor intensive than
c++, particularly with more complex operations. However, great improvements have
been made since Flash Player 9 to address these performance concerns. The inclusion of
native 3D support is also a massive advantage as the 3D math is handled internally by the
flash engine, greatly improving performance. Action script 3.0 also makes the jump from
scripting language to a more object orientated design which both improves development
time and the ability to handle complexity. Adding up all these advantages it was decided
to code the prototype in Action Script 3.0 using the Flash CS4 SDK running Flash Player
10.
There are a number of 3D engines built for use with Flash Player 10 such as Away3D and
Papervision3D. These engines are designed to run over the Flash Player and include a lot
of 3D functionality. However all this extra functionality comes with a decrease in
performance. Although not noticeable for smaller data models, a larger model running on
one of these engines would become very processor intensive. A lot of the in built
functionality would not be required by the tool as it was not generating complex shapes
so it was decided to code the solution from scratch just using the Flash engine.
3.2.1.2. Framework
The use of a design framework is an important resource in the building of scalable,
flexible and maintainable applications. Choosing the most appropriate solution among
available packages is critical so that functionality can be maximized, and time to
41
implement the solution can be minimized. Evaluating software options assists in
understanding how well a package does or does not fit relative to other marketplace
option.
The MVC framework is designed to separate an application’s coding interests into three
discrete tiers; Model, View and Controller. The model is used to maintain data and notify
observers when that data has changed. Models contain data and functionality that are
related by a common purpose. Views display specific portions of data in a form suitable
for interaction, in the case of the prototype this is in GUI elements. Multiple views for
different purposes can map to a single model. Controllers facilitate interaction between
the user and the application and handle events which affect the model or/and view. [31]
Fig 3.4
The aim of this prototype is to create graphical displays of tables which are very easy for
users to navigate through. The tool should simply and easily facilitate the manipulation
and visualization of these tables by the users. This navigation of 3D schemas is going to
require a great deal of user interaction with the system. This makes MVC a perfect design
pattern for the prototype to improve its approachability, scalability and flexibility. The
42
GUI can easily be split into functional models – for example, a modelling stage and a
menu, each of which will have multiple views associated with them. Each piece of
functionality – creating elements, saving a schema, etc can be mapped to specific
controllers. The exact breakdown of the component is laid out in the next section on the
GUI.
There are multiple MVC frameworks available for Flash projects. Somamvc, flashmvc,
cairngorm and puremvc are just a few which were investigated to see which would be
most compatible with this project. Three criteria were used to evaluate the different
frameworks to decide which would be best suited to the prototype:
Approachability – pureMVC has one of the largest online communities of all the
frameworks with a high signal to noise ration. There is a PureMVC Manifold Project,
which provides a well crafted central location for official PureMVC releases, and a
host of ports, demos, and utilities developed by the community. This wealth of
information provides a high quality code base to use and learn from. PureMVC is also
simple by design. It provides a solid foundation upon which to add your own
functionality. The framework itself is simple.
Scalability - The basic structure of PureMVC naturally lends itself to the creation of
common classes that can be reused across many projects. This allows for a loosely
coupled application that can be refactored and recycled easily.
Open-source – pureMVC has an open source license and having been ported to
multiple languages minimizes its internal and external dependencies.
PureMVC works by sending notifications from two places, proxies which refer to the
model and mediators which refer to the view. This is known as a “broadcast” or
“observer” structure. These notifications are mainly mapped to commands by the
controller. Mediators can also catch notifications sent from other mediators. All the
business logic is contained in the commands while the mediator is concerned with how
43
the view is displayed. [26] Further information on pureMVC can be found at PureMVC
Framework Overview
3.2.1.3. GUI
Below is a High Level Systems Diagram of the prototype. Constructors and visual objects
are depicted in rounded rectangles. Mediators and Proxies are depicted with circles and
Commands are depicted by squares. The Application Façade, which drives and relates
everything together, is depicted with an ellipse.
Fig 3.5
44
As can be seen from the system diagram above the prototype is quite a large project. To
make it easier to understand, analysis will be done in separate sections. Fig 3.6 shows a
wire frame interpretation of the GUI.
Fig 3.6
The GUI is composed of two main components - a modelling stage and an options menu.
The modelling section is the main stage where the data model is rendered. It has no set
width or height so expands and contracts based on user preferences. It was decided to
give it a black background to accentuate the 3D look. The stage contains multiple event
listeners which interact with the user. It is responsible for letting each entity or bubble
know when the user had moved and to update accordingly. It is also builds the
relationships between bubbles and creates the 2D representation of the tables dynamically
based on user interaction. Fig 3.6 shows a snap shot of the modelling stage.
45
Fig 3.7
Fig 3.8 shows the Modelling Stage Class Diagram. The intricacies of the modelling
process is discussed in detail further on in the Chapter but briefly what is included in the
diagram are the commands, proxies and mediators used to display and manipulate the
bubbles or tables on the stage.
46
ApplicationFacade
EntityMediator
SchemaDataProxyMenuDataProxy
AddBubblesToStageCommand
CreateSchemaCommand
StartupCommand
PrepViewCommandPrepModelCommand
-End1
*
-End2
*
-End3*-End4* -End5*
-End6*
-End7
*-End8 *
-End9
*
-End10*
-End11*
-End12*
-End13*-End14*
-End15* -End16 *-End17*
-End18
*
-End23*
-End24*
-End27*
-End28
*
EntityDataProxy
-End47*
-End48*
-End49
*
-End50 *
StageMediator
-End213*
-End214
*
GetSchemaCommand SaveSchemaCommandDeleteSchemaCommand
-End19*
-End20
*
MenuMediator
-End207*
-End208*
-End21*
-End22*-End25 *
-End26
*
-End29 *
-End30*
-End31*
-End32
*
-End33*-End34
*
-End35*
-End36
*
Fig 3.8
The menu section can be optionally shown or hidden by the user to give the modelling
stage more real estate. It was found that a large increase or decrease in the size of the
menu resulted in some components becoming distorted so the menu is of fixed width and
height and will not adjust when the stage size is increased or decreased. The user uses
the menu to create and update the schema. The menu allows the user to interact and
change the data on the model. It is used to add, delete and change both tables and
attributes. Once changes are saved in the menu, they appear on the stage. The menu
47
appears in the top right corner by default but is moveable so the user can drag and drop it
wherever they wish. Fig 3.9 shows a snap shot of the menu.
Fig 3.9
Fig 3.10 shows the Class Diagram of the Menu. Briefly what is included in the diagram is
the commands, proxies and mediators used by the menu to create, enhance or delete
schemas, tables and attributes.
48
ApplicationFacade
CreateSchemaCommandCreateEntityCommand
EntityDataProxy
EntityMediator
RetrieveSchemaCommand
SchemaDataProxy
-End101 *
-End102
*
-End103*
-End104*
-End105
*
-End106*
-End107*
-End108
*
-End109*
-End110
*
-End111*
-End112
*
-End113*
-End114
*
-End115*
-End116*
-End117 *
-End118
*
-End119
* -End120*-End121
*
-End122
*
-End123
*
-End124*
StageMediator
-End125*
-End126*
Fig 3.10
3.2.1.4. Middle Tier
It was decided to use PHP for the server side scripting requirement in the prototype. This
was chosen for multiple reasons. Firstly, it is free and open source so can legally be used
without requiring permissions or licenses. It is portable to both Unix and Windows and
uses very little resources in comparison to other scripting languages. Because of the
popularity and longevity of PHP there are a lot of tutorials and sample code available for
49
most operations giving it a very smooth learning curve. The final advantage is that it
interfaces very well with mySQL databases which are the choice of database for the
prototype. Fig 3.11 shows a basic visual representation of the interaction between the
prototype, XML, PHP and MySQL database.
Fig 3.11
There are 14 PHP scripts used server side to link the prototype to the database
register.php: This is a simple registration page. A user is required to register before
using the tool and creating a schema. A userid is required for data integrity. The page
simply connects to the database and registers a user. Username, email address and
password are required fields. The email address is checked to ensure it doesn’t already
exist in the BubbleUser table. All entries are also checked for malicious characters. Once
the email isn’t already in use and no malicious characters have been used, the details are
inserted into the database
login.php: A simple login page which takes a userid and password and passes them back
to the database to see if the user is a registered user. There is a link to a lost password and
50
lost username page as well in case the user has forgotten their password or username.
Upon login, a cookie is created which stores the users name and an encrypted version of
the user’s password.
lost_password.php: Gets an email address off the user and checks for a corresponding
address in the database. If the email address is valid, the corresponding password is
emailed to that address.
lost_username.php: Gets an email address off the user and checks for a corresponding
address in the database. If the email address is valid, the corresponding username is
emailed to that address.
logout.php: Simply logs the user out and ends their current session.
To run or use the remaining scripts, a user must be logged in to the system. Each time a
user logs in; a session cookie is created composed of their username and password. The
user id is pulled from the session cookie and this is checked at the beginning of each PHP
script before any other operation is carried out. If they are not logged in, then they are re-
directed to the login page. See Fig 3.12
51
/* Checks cookies to make sure user is currently logged in */
if(!isset($_COOKIE["user_derm116"])) {
echo("error=You need to be logged in to save a schema");
}
else {
$username = $_COOKIE["user_derm116"];
$password = $_COOKIE["pw_derm116"];
$check = mysql_query("SELECT * FROM BubbleUser WHERE username =
'$username'") or die(mysql_error());
while($info = mysql_fetch_array( $check )) {
/* If the cookie has the wrong password, go to the login page */
if ($password != md5($info["password"])) {
echo("error=You need to be logged in to save a schema");
die();
}
}
Fig 3.12
retrieveSchema.php: Retrieves information from the schema table in the database using
a schema id and user id sent from the prototype and sends back the schema info. Once the
schema info is received the prototype retrieves all entities in that schema.
retrieveEntities.php: Retrieves a schemas entities and their information from the
database using a schema id sent from the prototype. It then parses this into XML and
sends the XML result back to the prototype. A sample of the XML passed to the
prototype can be seen below.
52
<Entities>
<Entity>Example Entity</Entity>
<Entity>Example Entity 2</Entity>
<Entity>Example Entity 3</Entity>
</Entities>
retrieveAttributes.php: Retrieves all attributes from the database for a specific entity
using a schema id and entity name. The results are parsed into an XML result and sent
back to the prototype. A sample of the XML passed to the prototype can be seen below
<Attributes><Attribute>
<AttributeName>Example Primary Key</AttributeName><PrimaryKey>Y</PrimaryKey><ForeignKey>N</ForeignKey><RelatedTable></RelatedTable><RelatedKey></RelatedKey>
</Attribute><Attribute>
<AttributeName>Example Attribute</AttributeName><PrimaryKey>N</PrimaryKey><ForeignKey>N</ForeignKey><RelatedTable></RelatedTable><RelatedKey></RelatedKey>
</Attribute><Attribute>
<AttributeName>Example Foreign Key</AttributeName><PrimaryKey>N</PrimaryKey><ForeignKey>Y</ForeignKey><RelatedTable>Table 2</RelatedTable><RelatedKey>Table 2 Attribute</RelatedKey>
</Attribute></Attributes>
saveSchema.php: Receives schema information from the prototype and saves it to the
database. It creates a new row if the schema doesn’t already exist; otherwise it updates
the existing row in the database
53
saveEntity.php: Receives an entity from the prototype and saves it to the database using
the entity name and schema id. Returns a confirmation message to the prototype
saveAttribute.php: Receives an attribute from the prototype and saves it to the database
based on the schema id, entity name and attribute name. Returns a confirmation message
to the prototype
deleteSchema.php: Receives a schema id from the prototype and deletes it from the
database. Returns a confirmation message to the prototype
deleteEntity.php: Receives a schema id and entity name from the prototype and deletes
the corresponding entity from the database. Returns a confirmation message to the
prototype
deleteAttribute.php: Receives a schema id, entity name and attribute name from the
prototype and deletes it from the database. Returns a confirmation message to the
prototype
feedback.php: A simple web form with questions related to the experiments. It sends a
users experiment feedback and results to a specified email address.
54
3.2.1.5. Database
Schema
PK schemaId
userId schemaName
User
PK userId
userName password email firstName lastNameFK1 schemaId
Entity
PK,FK1 schemaIdPK entityName
Attribute
PK,FK1 schemaIdPK,FK1 entityNamePK attributeName
primaryKey foreignKey relatedTable relatedKey
Fig 3.13
Although MySQL is not as advanced as Oracle or Sybase, lacking some of the more
sophisticated capabilities, it is a free, fast and reliable open source relational database. It
is perfectly adequate for smaller applications and with such a large developer community,
there are a lot of mySQL resources out there making it very easy to learn and master. The
prototype used to prove this hypothesis will be using a very simple database design so
does not require any advanced database functionality.
There are four tables in the prototype database which can be seen in Fig 3.13.
Schema : This will be used to store a users set of schemas. Its primary key is
schemaID which is an auto-incremented integer. It has a foreign key called userid
which links it to the BubbleUser table and an attribute to store its name.
Entity: This has a one-to-many relationship with the schema table. It stores all
information required for an entity. At the moment this is just entity name but there
55
will be more attributes added as more functionality is added to the tool. Its
primary key is schemaId and entityName.
Attribute: This has a one to-many-relationship with the entity table. It stores all
relevant attribute information which includes attribute name, whether or not it’s a
primary key, whether or not it’s a foreign key and its related table and key if it has
any. Its primary key is schemaId, entityName, AttributeName.
BubbleUser : This contains all the user information. It has a primary key of userid
which is also an auto-incremented integer. FirstName and lastName are both
nullable columns so the user just needs to supply an email address and password
to use the tool.
phpMyAdmin was used to handle the administration of the above MySQL database. It is
a free piece of PHP software intended to handle the administration of MySQL databases
over the internet. It performs most generic SQL operations quickly without the need to
create SQL scripts allowing tables to be created and modified very easily and quickly.
Although the initial database design is very simplistic, this will evolve as the prototype
evolves which is where the phpMyAdmin tool will come in useful. More information can
be found at phpMyAdmin.
3.2.2. Prototype Design
This section briefly describes the design of the flash prototype developed to prove this
hypothesis. The design of the main areas is described below using a combination of class
and sequence diagrams along with a brief description of the selected functionality.
3.2.2.1. Initialization
During the initialization phase all components are created and loaded. If a user has no
existing schemas, then a sample schema is loaded into the tool. Both the menu and the
stage are populated with this schema. Below is the Class Diagram for the Initialization
56
ApplicationFacade
StageMediator
SchemaDataProxy MouseDataProxy
AddBubblesToStageCommand
StartupCommand
PrepViewCommand PrepModelCommand
End1
End2
End3
End4
End5
End6
End7
End8
End9
End10
End11
End12
End13
End14
End15
End16
End17
End18
EntityDataProxy
-End43
*
-End44*
-End45
*
-End46 *
-End203*
-End204
*
-End205*
-End206*
MenuMediator-End207*
-End208
*
CreateEntityCommand
EntityMediator
AddMenuToStage
-End209*
-End210
*
-End211
*
-End212 *
Fig 3.14
The sequence of events for the initialization is as follows
1. Application Façade registers commands and calls StartupCommand
2. StartupCommand calls the PrepModelCommand and PrepViewCommand
3. PrepModelCommand registers the StageMediator with the façade
4. PrepViewCommand registers the proxies with the façade
57
5. The SchemaDataProxy contains the information on the schema – how many
entities, they’re positions, etc.
6. The StageMediator creates a list of the notifications it is interested in and fires the
CreateSchemaCommand.
7. The CreateSchemacCommand generates the schema and updates the
SchemaDataProxy.
8. Once the SchemaDataProxy is updated it sends a notification that the schema is
ready to be added to the stage.
9. This sends out a notification to add the menu and the entities to the Stage.
10. The AddMenuToStageCommand creates a new menu and wraps it in a
MenuMediator. It the sends a notification to the StageMediator to add the menu to
the stage.
11. The AddBubblesToStageCommand creates a new EntityMediator for each entity
on the schema.
12. The EntityMediator creates a list of the notifications it is interested in and defines
its events and handlers.
13. The AddBubblesToStageCommand then loops through each bubble, sending it to
the StageMediator to add to the stage.
14. The StageMediator then adds each Entity to the stage.
3.2.2.2. Entity Construction
Each entity is composed of three main objects as well as multiple constructors.
SpaceObject – this object contains the entity camera and various settings which
are required to calculate the entities position as the user navigates around the
stage.
Sphere – this is what the user sees. Each sphere is made up of multiple smaller
objects mathematically positioned to give the impression of a 3 dimensional
sphere.
Table – this is the 2D representation of the entity or bubble.
58
There are also various constructors used to generate an entity
EntityMC – contains a definition for each entities SpaceObject and Sphere as well
some general information and list of the entities Attributes.
Attribute – contains some general information on each attribute such as whether
it’s a key and its name.
ForeignKey – contains information used to build up a relationship with it’s
connected entity
Below is a class diagram of the entity
Attribute
EntityMC
ForeignKey
SpaceObject
Sphere
-End143
*
-End144
*-End145
*
-End146*
-End147
*
-End148
*
-End151
*
-End152
*
-End149
*
-End150 *
Fig 3.15
1. A new EntityMC is generated along with its attributes either through the
MenuMediator or the RetrieveSchemaCommand.
2. The CreateEntityCommand is sent an entity to be constructed.
3. A new SpaceObject is created somewhere in the 3D space on the stage using a
random point generator.
4. A new Sphere is created based on the entities list of attributes.
5. Both are added to the EntityMC which is then sent to the AddBubbleCommand to
add it to the stage.
Below is the sequence diagram for the creation of a new entity.
59
CreateEntityCommand SpaceObject Sphere
CreateNewSpaceObj
CreateRandomPoint
CreateNewSphere
Fig 3.16
3.2.2.3. Navigation
A 3D spatial navigation approach similar to that found in a first person shooter arcade
game was adopted for the prototype. This uses the premise of a camera looking at a
scene. It is the camera which moves when the user navigates around the stage. Each
entity constantly seeks where the camera is and adjusts their position accordingly. Below
is the class diagram for the navigation.
EntityMediator
OnEnterFrameCommand
StageMediator
-End97*
-End98*
-End99 *
-End100
*
Fig 3.17
1. An onEnterFrame event is registered on the stage which firstly retrieves the schema
camera and then loops through each entity or bubble retrieving its personal camera.
60
2. The user navigates by either moving the arrow keys or the mouse
3. A navigation algorithm works out the cameras new position
4. A notification is sent to each entity to both render and update its position
Fig 3.18 shows the sequence diagram for the navigation of a single entity.
StageMediator OnEnterFrameCommand EntityMediato
OnEnterFrame()
sendNotification(OnEnterFrame)()
sendNotification(Update, entityCamera, entityID)()
Update()()
sendNotification(Render, entityCamera, entityID)()
render(entityCamera)()
retrieveCameras()
Zsorter()()
Fig 3.18
3.2.2.4. Schema & Entity Creation
A new entity can be created two ways.
A schema is retrieved from the database or a new schema is generated and
each entity in the schema is created and is added to the SchemaDataProxy’s
list of entities. See Fig 3.19 and Fig 3.20 for class and sequence diagrams.
The user creates a new entity in the menu and adds it to an existing schema.
See Fig 3.21 and Fig 3.22 for class and sequence diagrams.
61
SchemaDataProxy EntityDataProxy
EntityMediatorCreateSchemaCommand
-End55*
-End56*
-End57*
-End58*
-End59*
-End60
*StageMediator
-End77
*
-End78
*
-End79*
-End80
*
-End81
*
-End82
*
CreateEntityCommand-End83
*
-End84
*
-End85
*
-End86 *
-End87*
-End88*
Fig 3.19
The sequence of events for creating a new schema is as follows
1. The CreateSchemaCommand is called
2. A new list of entities is created and saved in the SchemaDataProxy
3. A new EntityCamera is created and saved in the EntityDataProxy
4. A new SchemaDataProxy is created and saved in the SchemaDataProxy
5. For each entity in the schema the CreateEntityCommand is called and a new
entity and corresponding EntityMediator is created
6. When the new EntityMediator is created, the relevant events and cameras are set
on the entity. The cameras are retrieved from the SchemaDataProxy and the
EntityDataProxy
7. This Entity is added to the list of entities in the SchemaDataProxy
8. The EntityMediator then sends an event to the StageMediator to add the entity to
the stage
62
StageMediatorSchemaDataProxy EntityDataProxy CreateEntityCommandCreateSchemaCommand EntityMediator
SetSchemaCam(camera)()
CreateNewSchema()
SetSchema()
SetEntityCam(camera)()
GenerateEntities()sendNotification(CreateEntity, entity)()
CreateEntity()
registerMediator(entity)()
sendNotification(AddBubble, entity)()
sendNotification(SchemaCreated)()
GetEntityCam()
GetSchemaCam()
Render(camera)()
Fig 3.20
63
SchemaDataProxy EntityDataProxy
EntityMediator
-End59*
-End60
*
StageMediator
-End79*
-End80
*
CreateEntityCommand-End83
*
-End84
*
-End85
*
-End86 *-End87*
-End88*
-End89
*
-End90
*
Fig 3.21
1. The MenuMediator calls the CreateEntityCommand passing over a list of
properties for the new entity and a new entity and corresponding
EntityMediator are created.
2. When the new EntityMediator is created, the relevant events and cameras are
set on the entity. The cameras are retrieved from the SchemaDataProxy and
the EntityDataProxy
3. This Entity is added to the list of entities in the SchemaDataProxy
4. The EntityMediator then sends an event to the StageMediator to add the entity
to the stage
64
StageMediator SchemaDataProxy EntityDataProxyCreateEntityCommand EntityMediator
CreateEntity
registerMediator(entity)
sendNotification(AddBubble, entity)
GetSchemaCam()
GetEntityCam()
Render(camera)()
Fig 3.22
3.2.2.5. Schema Retrieval
A schema is retrieved two ways. Either the schema is loaded on start-up or the user
selects to load a specific schema from the menu. A connection is opened up to the
database through a PHP script and the XML for the schema is retrieved using its unique
id and sent back to the schema retrieval class. This then generates and creates the schema.
See class diagram below.
65
RetrieveSchemaCommand
SchemaDataProxy
EntityDataProxy
EntityMediator
-End59*
-End60
*StageMediator
-End79*
-End80
*
CreateEntityCommand-End83
*
-End84
*
-End85
*
-End86 *-End87*
-End88*
-End89
*
-End90
*
-End93
*
-End94
*
-End95*
-End96
*
Fig 3.23
The sequence of events for retrieving an existing schema is similar to creating a new
schema. A sequence diagram is shown in Fig 3.24.
1. The CreateSchemaCommand is called. This connects to the mySQL database
through the PHP script described in the above section and retrieves an existing
schema.
2. A new list of entities is created and saved in the SchemaDataProxy.
3. A new EntityCamera is created and saved in the EntityDataProxy.
4. A new SchemaDataProxy is created and saved in the SchemaDataProxy.
5. For each entity in the retrieved schema the CreateEntityCommand is called and a
new entity and corresponding EntityMediator is created.
6. When the new EntityMediator is created, the relevant events and cameras are set
on the entity. The cameras are retrieved from the SchemaDataProxy and the
EntityDataProxy.
7. This Entity is added to the list of entities in the SchemaDataProxy.
8. The EntityMediator then sends an event to the StageMediator to add the entity to
the stage.
66
RetrieveSchemaCommand StageMediator SchemaDataProxy EntityDataProxyCreateEntityCommand EntityMediator
RetrieveSchemaXML()
TranslateXML()
SetSchema
SetSchemaCam(camera)
SetEntityCam(camera)
sendNotification(CreateEntity, entity)
CreateEntities()
CreateEntity()
registerMediator(entity)()
GetSchemaCam()
GetEntityCam()
Render(camera)()
sendNotification(AddBubble, entity)()
sendNotification(SchemaCreated)()
Fig 3.24
3.3. System Implementation
This section discusses the implementation of some of the more complex functionality in
the prototype.
3.3.1. Entity Creation
An Entity or Bubble is composed of multiple constructors. These are mainly used for the
schema save and generation. Each entity has a list of attributes. Each attribute then can
67
have a foreign key which contains the attribute and table the key is related to. This is a
fairly standard OOP design. Each entity in turn is also composed of two objects.
The SpaceObject is used to calculate an entities position and update it based on the user’s
movement around the stage. It is basically a constructor which specifies some vector co-
ordinates used to describe the entities position in 3D space. The SpaceObject is set up
similarly to both the SchemaCamera and the EntityCamera. Both are basically
constructors containing vector coordinates. As these coordinates change, a vector
algorithm is used to update the space objects position and so make the entity look as if it
is moving.
The targetObject, which is what the user sees on the screen, is expanded from a sample
tutorial in 3D matrix rotation found at Flash&Math. It is a sprite made up of multiple
smaller movieclips built in circles to generate a sphere or 3D bubble. Sprites are basically
movieclips generated at runtime which do not require a timeline. It uses three vector
arrays of numbers to generate the sphere from the attributes.
phiTilt: Phi is the vertical angle measure from the vertical angle pointing
downwards. For each circle of movieclips, phi is constant.
thetaStep: Theta is the horizontal angle measured from the horizon axis coming
out of the screen. ThetaStep contains the angular distances between each sprite on
the sphere.
jLen: the vertical angle between each circle of movieclips.
The below function builds up the sphere by positioning each attribute movieClip on a
different point in 3D space. The midpoint of each child movieclip is calculated using the
below formula
68
x = rad * sin(phi) * sin(theta)
y = -rad * cos(phi)
z = -rad * sin(phi) * cos(theta).
Fig 3.25
One of the drawbacks of Flash Player 10 is that there is no internal depth sorting done.
Depth sorting was possible in AS2 by using an internal function called swapDepths. This
was an incredibly inefficient function which looped through all the objects on stage,
without first sorting them, constantly removing and re-adding them. This became very
processor heavy as the number of objects on the stage increased and so has been removed
from AS3. This prototype uses a set of open source classes written by Ralph Hauwert and
hosted on Google Code by Lee Brimelow to reposition the clips in Z space.
3.3.2. Create Relationships
Relationships between entities or bubbles are created dynamically at runtime. There is a
built in graphics library in flash which contains two methods; lineTo and moveTo. These
can be used to draw a line between two 2D points. The drawback of these methods is that
they take a 2D point as a parameter. Since the points Z co-ordinates are not used; the line
is not scaled.
To enhance these methods to generate a 3D line, the localToGlobal method was used.
This is an internal method in the flash engine which converts a display objects local
coordinates to their corresponding display coordinates. A static point was set on the entity
on creation and this point was used to create the line. It was then connected to the
corresponding point on the related entity. See Fig 3.26.
69
foreignKey.connectionLine.graphics.moveTo(primaryEntity.localToGlobal(primaryEntity.centrePoint).x, primaryEntity.localToGlobal(primaryEntity.centrePoint).y);
foreignKey.connectionLine.graphics.lineTo(connectingEntity.localToGlobal(connectingEntity.centrePoint).x, connectingEntity.localToGlobal(connectingEntity.centrePoint).y);
Fig 3.26
3.3.3. Schema Deletion, Retrieval & Save
A mySQL database is been used to store the schemas used in this prototype. As
mentioned earlier this is a very simple database so will not be discussed in great detail.
Nine PHP scripts are used on the server to facilitate communication between the
prototype and the database.
The original approach to saving the schema was to generate an XML representation of
the schema and save this out to the database as a single object in the database. This object
would be retrieved and parsed on the flash side to regenerate the schema. It was
discovered that this approach was not practical with larger schemas due to string length
limitations in Flash. As a result, it was decided to split the operation into three chunks.
These are discussed below.
A schema is saved in three separate operations. These all operate similarly. Firstly the
variables required by the PHP script to update the data are created. These variables are
then added to a URL Request object. Finally a URL Loader object is created to process
the request. The Loader declares a complete and an IO Error event handler. The IO Error
handler catches any connection issues with the server. These could result if the server is
down or depending on the security settings on the user’s machine. It notifies users to
check their security settings to give the prototype permission to speak to the server.
70
Each PHP script has a small custom error function which is catches any server side
exceptions and passes them back as a result to the prototype. These are processed in the
above AS function to alert the users to any errors. See Fig 3.27.
function customError($errstr)
{
echo("error=".urlencode($errstr));
die();
}
Fig 3.27
The Complete event handler handles the result from the server. The first thing it does is
to call an error handling function to check if any errors occurred with the PHP script.
This makes sure the server returned some data and that no exceptions occurred on the
server side. If no errors occur then a true is returned which allows the method to continue.
Otherwise a false is returned and the command stops any further server interaction and
outputs an error message to the user. See Fig 3.28.
71
private function checkForServerErrors(loader:URLLoader):Boolean {
//Checks that there is some data returned from the server
if (loader.data.length > 0) {
//Cast the results to a URL Variables object. This splits them into
//their individual variables making them easier to work with
var variables:URLVariables = new URLVariables( loader.data );
//If there is no error message returned from the server then it
//operated correctly and we return true
if (variables.errorMsg == undefined)
{
return true;
}
else
{
//If an error has occurred set this to true so we don't send anymore
//requests to the server
errorOccurred = true;
//Retrieve the exact error and save it to be output to the user
errorMsg = variables.errorMsg;
return false;
}
}
//No data has been returned from the server
//Set the errorOccurred Boolean to true to stop any further requests to the server
errorOccurred = true;
//Return false to the calling method so that it does not try and process the results
return false;
}
Fig 3.28
72
If the saveSchema script is successful, each entity is sent to the saveEntity script using a
similar process. Once an entity has been successfully added each of its attributes is sent to
the saveAttribute script. There is a check on the save attribute complete event which
checks if it is the last attribute of the last entity to be added. If it is the user is alerted that
the schema was successfully saved.
The retrieval process is very similar to the save process. The same error handling
technique is used and again; it is split up into three separate sections. First the schema
information is retrieved. Next each entity in the schema is retrieved. Once each entity is
retrieved, each attribute in that entity is retrieved. The only difference is that an XML
object is created on the server side to represent each entity and attribute. This is sent back
to the prototype which parses the XML to generate the required Entity and Attribute
objects. The XML objects are described in greater detail in ection3.2.1.
The XML string returned from the PHP script is first parsed to an Action Script XML
object. For example in the case of an entity, an XML list is created based on the Entity
node. This acts similarly to an array list with each Entity Node been an item in the array
as seen in Fig 3.29.
var xmlData:XML = new XML( loader.data.entityValues );
var entityList:XMLList = xmlData.Entity;
Fig 3.29
It is then very simple to loop through each entity and extract the required data. For
example, to extract the entity name, the following code is used (3.30).
var entityName:String = entityXml.entityName.text;
Fig 3.30
73
Deletion of a schema uses the same process. To delete a schema, firstly the schema is
deleted from the Schema table. Next each entity with that schema id is removed from the
Entity table. After each entity is removed, all attributes for that entity are removed from
the Attribute table.
3.3.4. Navigation
As mentioned earlier in the chapter, a 3D spatial navigation approach similar to that
found in a first person shooter arcade game was adopted for the prototype. This approach
is based on cameras which move around the stage manipulating the position of the
entities on the stage. There are two cameras used in this approach
Entity Camera: Each individual entity has its own camera.
Schema Camera: This is the main camera concerned with the overall stage
The user can navigate around the stage with either the mouse or the keyboard arrow keys.
With the arrow keys, the user can zoom in and out, or move to the left or right based on
the camera position. Using the mouse the user can navigate at angles, for example zoom
in while moving to the left.
Each entity has an event for re-calculating its position on the stage. The
OnEnterFrameCommand loops through each entity in the schema list firing off this event.
Since this is called from the OnEnterFrame event on the StageMediator, it is constantly
fired so the entities positions are continuously been recalculated and updated. As either
the mouse or arrow keys move, the positions of both the entity cameras and schema
camera are re-adjusted.
The Render function in the EntityMediator then calculates the new position, rotation and
scale of the entity based on the cameras new location. The position is simply calculated
by subtracting the cameras x, y and z locations from the entities x, y and z locations as
seen in Fig 3.31.
74
var x:Number = entity.spaceObject.x - camera.x;
var y:Number = entity.spaceObject.y - camera.y;
var z:Number = entity.spaceObject.z - camera.z;
Fig 3.31
3D rotation is a lot more complicated than 2D rotation as an axis of rotation must be
specified. In 2D, the axis of rotation is always perpendicular to the Z axis but in 3D it can
have any spatial orientation. Euler angles are often used to describe object rotation in 3D
space. Generally the rotation is split into three separate parts: rotation around the Y axis
(yaw), rotation around the x axis (roll) and rotation around the Z axis (pitch). A yaw roll
pitch (Y X Z) transformation is used in the prototype. A snippet of the code is shown in
Fig 3.33.
The corresponding Matrix Algorithm for this can be seen in Fig 3.32
Fig 3.32
75
//y axis rotation
var radians:Number = camera.ty*(Math.PI/180);
var xTemp:Number = Math.sin(radians)*z + Math.cos(radians)*x;
var zTemp:Number = Math.cos(radians)*z - Math.sin(radians)*x;
x = xTemp;
z = zTemp;
//x axis rotation
radians = camera.tx*(Math.PI/180);
var yTemp:Number = Math.cos(radians)*y - Math.sin(radians)*z;
zTemp = Math.sin(radians)*y + Math.cos(radians)*z;
y = yTemp;
z = zTemp;
//z axis rotation
radians = camera.tz*(Math.PI/180);
xTemp = Math.cos(radians)*x + Math.sin(radians)*y;
yTemp = Math.sin(radians)*x - Math.cos(radians)*y;
x = xTemp;
y = yTemp;
Fig 3.33
A scale factor is also calculated based on the cameras Z position and later applied to the
sphere movieclip as seen in Fig 3.34.
var scale:Number = camera.fl/(camera.fl+z);
Fig 3.34
76
As mentioned above, Flash 10 does not do z-sorting natively. A similar approach is taken
to sorting the objects on stage as was used to sort the sprites in the bubble sprite. After
each entity is moved on the stage, it is sorted based on its Z position.
77
4. Experimental Design and SetupHaving given a detailed description System Design and Implementation in the previous
chapter, the experiments which will be conducted with the prototype are outlined in this
section.
4.1. Websites
As this research was conducted remotely, it was not feasible to organize a supervised lab
session for users to perform their testing. As a result, it was decided to create a project
website to host all the project artefacts. It was created using a mixture of HTML, PHP
and JavaScript. Users were asked to register for the site before been allowed to use any of
its resources. To save a schema, a unique user id is required. This is assigned to a user
when they register on the site. The site uses cookies to check if a user is logged in. If an
invalid user tries to access any of the project web pages they are automatically redirected
to the login screen. The web site is split into a few main sections.
Admin: This section includes pages to register, login, logout and update personal
information. On login a cookie is created with the users email and encoded password. To
access any of the test resources, users must be a member of the site.
Testing Resources: This section includes a separate page for each experiment which
explains each experiment in details. It also includes a results and feedback page which is
a simple web form. Users are asked to submit in their results on this page for each
experiment. These results are then emailed back to the project owner. Also included here
are some user guides and quick tips to get a new user started.
Project Resources: This section includes this research paper in both PDF and word doc
formats as well as a zip file containing all source code for both the prototype and the
website.
The website can be found at the following link: Boilgeog
78
4.2. Experimental Design
Following from the description of the implementation of the prototype in the preceding
sections this section now describes how this basic prototype was used to investigate
specific issues relating to the thesis hypotheses, as outlined in Chapter 1.
As mentioned earlier on in this paper, a case study approach is been taken to prove out
the thesis hypothesis. A control group was selected comprised of ten users working in
various roles
Data Analyst x 1
Business Analyst x 1
Systems Analyst x 2
Software Engineer x 4
o Application (Front-end) Developer x 2
o Application Services (Middle-Tier) Developer x 2
Average User x 2
The premise of the hypothesis was that by utilizing 3D modelling capabilities together
with modern data visualization techniques, the process of data modelling could be
significantly simplified to the point that users in multiple disciplines could easily
understand a model. These experiments used a variation of users who would have had
different exposure to data modelling to try and make the results as varied and as
representative of a wider community of users as possible.
Each user was sent a link to the website which first asked them to register. Once
registered they had access to all the project resources including a user guide which
described the operation of the prototype and each experiment came with a description of
what the user was to do as well as a feedback form to grade the use of the tool over
various criteria.
79
Each user conducted the experiments individually and with no time constraints, although
they were asked to provide some metrics in the other comments section of the feedback
form. The experiments got progressively more challenging. Before the user could start on
any of the experiments they had to first register on the site. This was to provide them with
a unique id to maintain data integrity in the database.
Each of the four experiments has an emphasis on usability as well as on one other key
component of data modelling. Each experiment is discussed in more detail below. The
overall goal of the experiments was for users to find the new methodology more intuitive
than a classic approach and for the tool to score high on usability. These would show
whether the adoption of a 3D methodology did in fact improve the clarity and reduce the
complexity of a data model and whether the use of modern data visualization techniques
improved the readability and use of data models.
4.3. User Guide
The user guide is available for download on the project website.
4.4. Feedback Questions
Each statement below should be graded between one and five with five referring to the
statement been most true and one referring to it been most negative. A three would mean
the question is either not applicable or the user has no opinion either way. The form also
includes a comments section for any other feedback not covered in the questions
The experiment was well laid out and it was easy to get started
The tool was user friendly
I found it easy to find data in the model
This data model is a lot easier to read in 2D format
I found it easy to add data to the model
I found myself lost in the model after navigating away from the original position
80
It was a lot easier to add data with a pencil and paper than using the prototype
I did not find the need to constantly consult the user guide
Data modelling concepts such as relationships and keys are easier to find in the
prototype
I found it easy to navigate around the model
There are pieces of both the GUI which is the implementation of the data visualization
techniques and the Bubble Modelling methodology in the majority of the questions. This
was due to the fact that from a user’s point of view both are intertwined. They are using
the tool to test the methodology. However, each factor has two specific questions.
There are two questions on navigation whose results do not have an impact on the Bubble
Modelling methodology. A poor navigation experience does not mean the new
methodology has failed, just that the data visualization techniques chosen do not translate
well to data modelling.
Similarly there are two questions isolated to the bubble modelling methodology. There is
one on finding data in the tool and a second on how well concepts are represented in the
tool. If the user finds the data poorly represented by the new methodology but still finds it
easier to navigate around the data in the chart, than the use of data visualization
techniques would be validated but the 3D approach would fail.
Although not all questions are applicable for each experiment it was decided to use the
same set of questions for each. This was to measure if users’ results would become more
positive, more negative or remain the same as they worked through the experiments.
These metrics will give a more accurate representation of the overall success or failure of
both the experiments and the hypothesis.
81
4.5. Case Study
-employee_id-job_title_code-address_id-first_name-last_name-email-gender-dob-gender
Employees
-job_title-wage_type-manager
Employee_Type
-wage_type-employe_type-pay_period-rate
Wage_Type
-employee_id-wage_type-eligibility-amount
Bonus
-payment_method_id-employee_id-description
Payment_Method
-address_id-street_address-city-zip_postcode
Addresses
-employee_id-payment_method_id-account_num-billing_address
Bank_Details
-deduction_type_id-deduction_description-deduction_amount
Deduction_Type
-project_id-task_id-task_description-total_hours_billed
Project
-task_id-task_descripition-hours_billed
Task
-timesheet_id-employee_id-project_id-timesheet_period-total_hours
Timesheet
-employee_id-payment_method_id-timesheet_id-deduction_type_id-total_pay-
Account
-employee_id-deduction_type_id-total_deductions-deductions_this_year
Deductions
-End179
*
-End180
*-End181
*
-End182
* -End183
*-End184
*
-End185
*
-End186
*
-End187
*
-End188 *
-End189
*
-End190
*
-End191
*
-End192
*
-End193
*
-End194
*
-End195
*
-End196
*
-End197
*-End198
*-End199*
-End200*
-End201
*
-End202
*
Fig 4.1
Above is the initial database design for the Case Study Model which is used in the
experiments to prove out this hypothesis. In the experiments users are asked to participate
in, they will be asked to create a simpler version of the example solution above. As they
work through the experiments they will be asked to enhance their initial solution to
gradually support a more complex system. They will be asked to rate the experience in
comparison to doing it with the traditional 2D approach.
4.6. Experiment 1 – Navigation
This experiment was the easiest and was designed to get the users familiar with the tool.
On a users first successful login to the site they were redirected to a quick tips page
82
which was a watered down version of the user guide. This basically outlined some of the
key elements of the prototype and the layout of the website.
Once they’d finished with the quick tips they are redirected to the first experiment page.
This contains their instructions on the first experiment and a link to the prototype.
As mentioned this experiment is designed to familiarize users with the tool. The main
goal of this experiment is to ascertain how user friendly the tool is and to familiarize the
user with the bubble modelling concepts. It was chosen as an acid test for the usability of
the tool as well as the usefulness of the 3D methodology. Although alone it could not
prove the hypothesis, it could easily disprove the hypothesis. If users are not comfortable
using the tool with a simple data model then this solution will not reduce the complexity
or improve the usability of a more complex data model disproving the hypothesis.
A very simple data model for an online charity bookstore is populated.
-cartID-userID-bookID-qty
Cart
-bookID-title-ISBN-authorID-publisherID-charityID-price-status
Book
-authorID-authorName
Author
-publisherID-publisherName
Publisher
-charityID-charityName-description-total_raised
Charity-userid-username-firstname-lastname-email-password
User
-End169
* -End170
*
-End171
*
-End172
*
-End173
*
-End174
*-End175
*
-End176
*
-End177
*
-End178
*
Fig 4.2
83
4.7. Experiment 2 – Create New Schema
This experiment assumes the user has completed experiment one and is relatively familiar
with the tool. It also assumes that the user is familiar with basic concepts of data
modelling. However there is a link provided to an online tutorial which will provide a
user with all the skills required to complete the experiment.
In this experiment the user is asked to create a new data model from scratch. This model
is for a payroll system. The following is the description given to the users.
The company you work for are expanding and have decided to move from their manual
pen and paper payroll system to a software solution. You have been asked to design the
database to support this new system. The system must contain some basic employee
information, their pay grade and their pay rate. Note some employees are paid hourly and
can earn overtime while others are paid monthly and qualify for a yearly bonus.
Users were asked to model out this database from scratch using only the prototype. What
is required here is to decide what tables are needed and what attributes are required in
each table. Also relationships between tables must be specified. Users were not requested
to normalize their designs but can if they wish.
Once completed, users are asked to perform the same task using a pencil and paper. This
was used for comparison in the results. They’re solution was then given to another user to
interpret.
This experiment has two goals. One is to ascertain how intuitive and easy it is to add data
using the tool. The second is how easy the generated designs are for other users to follow.
This is the first comparison between the existing methodologies and the new 3D
methodology so if it is unsuccessful the hypothesis will be disproved.
84
4.8. Experiment 3 – Update Existing Schema
This experiment assumes the user has completed experiments one and two and is
relatively familiar with the tool. In this experiment users are asked to enhance the data
model created in the previous experiment. Below is the description given to the users.
Tax Season has come and gone and employees found the new system very useful for
helping them with their returns. It has been such a success that it has been decided to
expand the system to now also include other deductions. This will include health and life
insurance as well as retirement plans. The database needs to be enhanced to support this
new functionality.
Again users are asked to just use the prototype to enhance their models. They need to
decide what, if any, new tables and attributes are required and how they will relate with
the existing model. Again users are simply asked to build relationships between their
tables, no other relational rules were asked to be adhered to.
Similar to Experiment two, once the users have completed the experiment on the
prototype they are asked to do the same thing with some pencil and paper. This is to
ascertain preference and to measure improvement by using the new technique and tool.
Similarly to experiment two, this experiment has multiple goals. To enhance the data
model users must be able to easily see the current information in the model – current
tables, attributes and relationships and be simply able to add to and change this data. This
will require the ability to easily navigate around the data and for the data to be displayed
in a clear, readable and concise manner. Failure in the first would show that the use of
data visualization techniques do not improve the simplicity or usability of data models
while failure in the second would show that the new 3D approach does not offer any
improvement on the existing methodologies.
85
4.9. Experiment 4 – Find Table Information
This experiment assumes the user has completed the previous three experiments and is
very familiar with the tool at this stage. The user is given a data model representing a take
out pizza shop and is asked to find certain data in the model. This data model is adapted
from an example data model found at Data Base Answers
-customer_id-customer_address_id-customer_name-customer_phone-customer_email
Customers
-address_id-street_address-city-zip_postcode
Addresses
-employee_id-employee_address_id-employee_name-employee_phone-other_employee_details
Employees
-order_id-customer_id-employee_id-order_status_code-price
Orders
-pizza_id-order_id-pizza_price
Pizza-pizza_id-topping_code-topping_price
Toppings
-employee_id-payment_code-job_code
Employee Type
-payment_code-emplyee_type-rate
Wage_Type
-order_status_code-description
Order Status
-End153*
-End154*
-End155
*
-End156
*
-End157 *
-End158 *
-End159
*
-End160
*
-End161*
-End162*-End163*
-End164*
-End165
*
-End166
*
-End167
*
-End168
*
Fig 4.3
Please locate the following in the pizza delivery diagram:
- Tables
o Orders
o Wage_Type
o Addresses
o Toppings
- Attributes
o Description
o Job_Code
86
o Employee_Name
o Topping_price
- Foreign Keys
o Topping_code
o Customer_id
o Customer_address_id
o Order_Status_Code
- Primary Keys
o Customer_id
o Topping_code
o Employee_id
o Address_id
Unlike the last two experiments users are asked to just locate this information using the
prototype. Usability is the main metric used to measure the success of this experiment.
Users are now familiar with the new methodology and the prototype so will give a more
biased result set based on whether or not they like the new approach. They are likely to
have decided whether or not they found this approach better or worse from the previous
three experiments. They are no longer been asked to compare the approaches but give
their results purely on their experience with the prototype. Comparing these results to the
previous experiment will show if users’ opinions remained the same given the option of
either approaches or whether they gave more positive or negative feedback when only
given the option of the new system.
87
5. ResultsThis chapter presents results on the four experiments outlined in chapter four which were
conducted using the prototype. The first experiment was conducted with only the
prototype while the other three involved using both the prototype as well as a pen and
paper approach. On each experiment users were asked to fill in the online feedback form
described in the previous chapter.
Experiment one was designed to familiarise the user with the prototype. The goal of this
experiment was to outline the new bubble modelling methodology and highlight the
comparisons and differences with a classic technique.
There are three main operations associated with data modelling. The first is creating a
data model based on some pre-defined criteria. The second experiment examines the
impact of using the 3D approach to data modelling as opposed to the classic 2D
approach. Criteria used to examine the results include ease of use, and simplicity of
design in comparison to creating the same model with a 2D methodology.
The second main operation includes enhancing an existing data model to support a more
complex system. The third experiment investigates using the prototype to enhance the
data model created in the second experiment. Similar to the second experiment, the
results are examined based on ease of use and simplicity of design in comparison to
doing the same enhancement to an existing 2D model.
Finding data in a data model is the third and final operation associated with data
modelling. The fourth and final experiment examines using the prototype to find various
data elements on a data model which users have not seen before. Similarly to the previous
two experiments the criteria used to examine the results include ease of use, simplicity of
design and time taken to complete the experiment. Again these results are compared to
conducting a similar operation on a 2D model.
88
The next sections present results on this experiment. Results are split into three sections.
Firstly the user feedback is documented and analysed. The second section investigates
and plots the general trends of the feedback and discusses any exceptions which occurred.
The final section interprets the results and concludes whether or not they back up the
hypothesis. Both the Bubble Modelling methodology and the prototype are analyzed in
conjunction to identify their effect on users' performance in the tasks.
All the graphs and tables used in the upcoming sections refer to questions by the question
number. The questions, along with their numbers are shown below:
1. The experiment was well laid out and it was easy to get started
2. The tool was user friendly
3. I found it easy to find data in the model
4. This data model is a lot easier to read in 2D format
5. I found it easy to add data to the model
6. I found myself lost in the model after navigating away from the original position
7. It was a lot easier to add data with a pencil and paper than using the prototype
8. I did not find the need to constantly consult the user guide
9. It was a lot easier to find data in the 3D version of the data model
10. I found it easy to navigate the model
5.1. Experiment 1 – Getting Started
As outlined in section 4.4, the goal of this experiment was to familiarize the user with the
new modelling methodology as well as the use of the prototype. A very simple model
consisting of five tables was pre loaded into the prototype. The user was asked to
navigate around the model, find each table and show their relationships and attributes.
This experiment, although simple, was a good initial test for the usability of both the
bubble modelling approach and the prototype. If the users’ experience was poor for a
89
simple implementation of the new approach, then it is not going to be good for a more
complex example which would disprove the hypothesis.
5.1.1. User Feedback
This section documents the average feedback obtained for the questions outlined in
Section 4.2. These results are then analyzed and interpreted in relation to the hypothesis.
Fig 5.1 shows a table of all the results.
Questionsuser 1
user 2
user 3
user 4
user 5
user 6
user 7
user 8
user 9
user 10
Q1 4 4 5 4 4 4 4 5 4 4Q2 4 4 4 5 5 4 4 5 4 4Q3 4 3 1 3 3 1 3 4 4 3Q4 3 3 3 3 3 3 3 3 3 3Q5 3 3 3 3 3 3 3 3 3 3Q6 4 4 3 4 4 4 4 3 3 4Q7 3 3 3 3 3 3 3 3 3 3Q8 5 4 3 4 5 3 4 4 5 4Q9 3 3 3 3 3 3 3 3 3 3Q10 4 5 3 4 5 3 3 5 4 4
Fig 5.1
These results are then plotted into a line chart in Fig 5.2 for a better visual representation
of the feedback.
90
Experiment 1 Results
0
1
2
3
4
5
6
user 1 user 2 user 3 user 4 user 5 user 6 user 7 user 8 user 9 user 10
Users
Que
stio
ns
Q1
Q2
Q3
Q4
Q5
Q6
Q7
Q8
Q9
Q10
Fig 5.2
As mentioned above, the goal of this experiment was twofold. Firstly it was devised to
act as a gentle introduction to the bubble modelling methodology approach and to
familiarise the user with the prototype. Secondly, and more importantly, it was an initial
test for the usability of the tool.
Some of the results above were expected. As the model been used was very simplistic
and the users’ were not asked to complete many tasks, non-committal answers were
expected for some of the questions. This was because the questions were not applicable,
either due to the simplicity of the test model or because the user was not asked to perform
certain tasks. The following questions were of greatest interest for this experiment
1. The experiment was well laid out and it was easy to get started
2. The tool was user friendly
5. I found it easy to find data in the model
91
8. I did not find the need to constantly consult the user guide
10. I found it easy to navigate around the model
These questions highlighted the users experience with the tool. The first two and last two
questions unanimously scored high marks with all testers with very little deviation.
Although this is not a relevant marker for the hypothesis due to the simplicity of the
model used, it is a useful initial test to show that the new approach and tool do not
disprove the hypothesis.
There was some discrepancy with the results of the third question. These are investigated
in the following section
5.1.2. Trends & Exceptions
This section discusses the general trends identified in the data. It also discusses and
dissects any exceptions which occurred. For clarity, the below graph only shows the
results of the five questions highlighted above.
92
Usability Results - Experiment 1
0
1
2
3
4
5
6
user1
user2
user3
user4
user5
user6
user7
user8
user9
user10
Users
Que
stio
ns Q1
Q2
Q5
Q8
Q10
Fig 5.3
As can be seen, questions one, two, four and five do not show much deviation with the
results been generally positive. However, questions three, which asked if the user found it
easy to find data, shows a large split in opinion with two users giving it poor feedback
while others ranged from good to no opinion.
As outlined in the previous chapter, a range of users, with differing experience with data
modelling, were used to conduct the testing. The two users who gave this question
negative feedback had no previous data modelling experience. Although they had
completed the data modelling tutorial, they do not come from a technical background so
there is a certain learning curve. As a result it is expected that they would initially have
more trouble using the prototype. One goal of this experiment was to familiarise users
with the bubble modelling methodology. Thus, we are not overly concerned about users'
feedback regarding their initial learning curve with tool. However, if this feedback
remains throughout the experiments, then we should pay further attention to such
feedback and any related comments.
93
5.1.3. Interpretation of Results
These results would suggest that the prototype is both user friendly and very easy to get
started with. Users found the navigation both intuitive and easy to understand and were
generally able to explore the tool without too much guidance or interference. The one
negative result was with trying to find specific data in the model. This is been put down
to learning curve at the moment but is evaluated further in the upcoming experiments.
5.2. Experiment 2 – Create New Schema
As outlined in section 4.5, the goal of this experiment was to assess how easy it was to
create a new data model using the prototype and how easy the models created were to
understand. Users were asked to create a new data model based on their interpretation of
the case study outlined in Section 1.6. Once complete they were asked to look at another
user’s interpretation and analyse it to see if they could explain the system been modelled.
Users were not told that they were looking at a different interpretation of the same case
study.
Unlike Experiment 1, this experiment had a direct impact on proving the hypothesis.
Creation of a new data model is one of the key use cases for a data modelling system.
Therefore simplifying the creation of a new data model by using the new methodology
and prototype is one of the main criteria used to evaluate the hypothesis
5.2.1. User Feedback
This section documents the average feedback obtained for the questions outlined in
Section 4.2. These results are then analyzed and interpreted in relation to the hypothesis.
Fig 5.4 shows a table of all the results.
94
Questionsuser 1
user 2
user 3
user 4
user 5
user 6
user 7
user 8
user 9
user 10
Q1 4 4 5 4 4 4 4 5 4 4Q2 4 4 4 5 5 4 4 5 4 4Q3 4 3 2 4 3 2 3 4 4 3Q4 2 2 3 3 2 4 3 2 2 3Q5 3 4 4 3 3 3 4 4 3 4Q6 2 2 3 2 2 2 3 1 1 2Q7 3 3 2 2 2 2 3 1 3 2Q8 4 3 5 4 4 5 4 4 5 4Q9 4 3 4 4 3 3 4 3 4 4Q10 4 5 3 4 5 3 3 5 4 4
Fig 5.4
These results are then plotted into a line chart in Fig 5.5 for a better visual representation
of the feedback.
Experiment 2 Results
0
1
2
3
4
5
6
user1
user2
user3
user4
user5
user6
user7
user8
user9
user10
Users
Que
stio
ns
Q1Q2Q3Q4Q5Q6Q7Q8Q9Q10
Fig 5.5
95
As mentioned above, the main goal of this experiment was to evaluate the improvement
in creating a new data model using the new methodology and tool. A more in-depth
analysis of the usability of the tool was also conducted in this experiment. This
experiment was used to ascertain whether the discrepant results in the previous
experiment were due to the learning curve or a flaw in the new system.
Some of the results were expected. It was expected that users would be familiar with both
the tool and the methodology after completing experiment one so would not require much
direction. There are two sets of questions of interest here. The first were the questions on
adding data.
5. I found it easy to add data to the model
7. It was a lot easier to add data with a pencil and paper than using the prototype
These questions were used to evaluate the main use case in this experiment. How easy
was it to create a new data model using the new approach and prototype and how did it
compare to creating a similar model with a classic approach. There was little deviation in
question five and no one seemed to have issues adding data to the model. Of greater
interest are the results from questions seven which asked users to compare the new
methodology with a classic data modelling approach. These results are investigated more
in the following section.
3. I found it easy to find data in the model
4. This data model is a lot easier to read in 2D format
6. I found myself lost in the model after navigating away from the original position
9. It was a lot easier to find data in the 3D version of the data model
10. I found it easy to navigate around the model
These questions evaluated the usability of the tool. They mainly refer to results from the
second part of the experiment where users were asked to evaluate another users design.
There is some deviation between results but these results are not only reliant on the
96
prototype but also on how clear a design another user created. They are discussed in
greater detail in the next section.
5.2.2. Trends & Exceptions
This section discusses and plots the general trends extracted from the results. It also
discusses and dissects any exceptions which occurred within the results. The first subset
of results which refer to the creation of the data model will be evaluated first. The
following line chart (Fig 5.6) shows the spread of the results
Create Data Model - Experiment 2
0
1
2
3
4
5
user1
user2
user3
user4
user5
user6
user7
user8
user9
user10
Users
Que
stio
ns
Q5
Q7
Fig 5.6
As mentioned earlier, there is little deviation between the results of question five. Users
either found it very easy to add data to the model or did not find it difficult. Question
seven has a slightly more diverse result set. 40% of users did not find it any easier to add
data using the prototype than if they were creating the model on paper. This was slightly
higher than anticipated. Some of this, again, can be put down to learning curve but it
would be expected that users would be familiar with the tool by the end of the
experiment. These users all had technical backgrounds with previous experience in data
modelling. They were not marking the new approach negatively but felt it was no easier
than doing the same thing with a pen and paper.
97
The second subset of results, which refers to the usability of the tool, is now evaluated.
The below line chart shows the spread of results.
Usability - Experiment 2
0
1
2
3
4
5
6
user1
user2
user3
user4
user5
user6
user7
user8
user9
user10
Users
Que
stio
ns
Q3Q4Q6Q9Q10
Fig 5.7
In general this section was successful as well. Users generally were positive in their
feedback and found it easier to navigate around the 3D model than to study an equivalent
2D model. One question that stands out as having a greater deviation between positive
and negative results is question three. This asks if data was easy to find in the model. As
mentioned earlier, the evaluation of the models was not only based on the ease of use of
the prototype and the intuitiveness of the bubble modelling methodology but also on the
model created by the user. In both cases where a user returned negative results, they
found it no easier to retrieve data from the 2D model. The users found it hard to relate
data on the model rather than find data on the model. As both users were new to data
98
modelling and had otherwise positive results, it was decided that these exceptions were
satisfactory
5.2.3. Interpretation of Results
According to the results, a majority of users found it a slightly easier and quicker to
create a schema using the 3D approach as opposed to using pencil and paper. The 40% of
users, who didn’t find it easier, did not think it was any harder than the pencil and paper
approach. Creating a data model is one of the key use cases associated with data
modelling so, the 3D approach needed to be at least as good as the traditional approach
for the hypothesis to be valid. In 60% of users it was slightly better so this is a positive
result.
The second set of results show that, in general, the majority of users found an
improvement in navigating around the data model and found it easier to find data using
the prototype. This helps to affirm the idea that incorporating a 3D approach as well as
using modern data visualization techniques can improve the usability of data models and
make them more intuitive to a greater audience. In the previous experiment, inconsistent
usability results were put down to a learning curve. The same users had difficulties with
this experiment but found the prototype easier to use and more intuitive than an
equivalent model in 2D format. Both had some issues finding data and identifying the
system in the model they evaluated but both also found it easier to navigate around the
data in the prototype. Since this was their first time looking at a relatively complex data
model. These exceptions are going to be put down to learning curve at the moment.
However, they are evaluated further in the upcoming experiments where the learning
curve should be less severe.
One common observation among users was that although it was very easy to create tables
and populate them, there was no efficient method to normalise tables. One common
method of data modelling was to create larger tables and normalise the relations until a
sufficient data model was created.
99
5.3. Experiment 3 – Update Existing Schema
As outlined in section 4.6, the goal of this experiment was to assess how easy it was to
update an existing data model using the prototype. Users were asked to update the models
they created in the previous experiment to support a more complex system
Similar to the previous experiment, this experiment had a direct impact on proving the
hypothesis. Enhancing an existing data model is one of the key use cases for a data
modelling system. It can also be one of the more time consuming and difficult activities
depending on a user’s familiarity with the system. Simplifying this process will be one of
the key criteria used to evaluate the hypothesis
5.3.1. User Feedback
This section documents the average feedback obtained for the questions outlined in
Section 4.5. These results are then analyzed and interpreted in relation to the hypothesis.
Fig 5.8 shows a table of all the results.
Questionsuser 1
user 2
user 3
user 4
user 5
user 6
user 7
user 8
user 9
user 10
Q1 4 4 5 4 4 4 4 5 4 4Q2 4 4 4 5 5 4 4 5 4 4Q3 4 3 4 4 4 3 4 4 3 3Q4 2 2 3 3 2 2 3 2 2 3Q5 3 3 4 4 4 3 4 4 4 4Q6 3 3 2 2 2 2 3 1 1 2Q7 2 1 2 1 2 2 2 1 2 2Q8 4 3 5 4 4 5 4 4 5 4Q9 4 3 4 4 3 3 4 3 4 4Q10 4 5 3 4 5 4 3 5 4 4
Fig 5.8
These results are then plotted into a line chart in Fig 5.9 for a better visual representation
of the feedback.
100
Experiment 3
0
1
2
3
4
5
6
user 1 user 2 user 3 user 4 user 5 user 6 user 7 user 8 user 9 user 10
Users
Que
stio
ns
Q1
Q2
Q3
Q4
Q5
Q6
Q7
Q8
Q9
Q10
Fig 5.9
Simplifying the process of enhancing an existing data model as well as making it more
intuitive was the goal of this experiment. Usability analysis was also conducted with the
assumption that the learning curve would be a lot more gradual than in previous
experiments. As a result, any exceptions in results would not be put down to learning
curve.
Most of the results obtained from this experiment were expected based on the results of
the previous experiments. Since the majority of users had given positive feedback in the
previous experiment it was expected that these results would not deviate much in this
experiment. Similar to the last experiment there are two sets of questions of interest here.
The first are the questions on adding and finding data.
3. I found it easy to find data in the model
5. I found it easy to add data to the model
7. It was a lot easier to add data with a pencil and paper than using the prototype
101
9. It was a lot easier to find data in the 3D version of the data model
To enhance an existing data model to support a more complex system it needs to be easy
to both find existing data and to add new data. These questions give an accurate
representation of how intuitive and easy it is to enhance the model created in the previous
chapter. There was little deviation in all four of these questions with the majority of users
giving positive feedback. This suggests that this section of the experiment was a success
but this will be discussed in greater detail in the next section.
2. The tool was user friendly
6. I found myself lost in the model after navigating away from the original position
10. I found it easy to navigate around the model
These questions evaluated the usability of the tool. They mainly refer to results from the
second part of the experiment where users were asked to evaluate another users design.
Questions two and ten both got positive results by the majority of users. Question six,
although slightly improving on experiment two still has some negative results. Some
users were still having problems navigating back to their original position in the data
model. This is discussed in greater detail in the next section.
5.3.2. Trends & Exceptions
This section discusses and plots the general trends pulled from the results. It also
discusses and dissects any exceptions which occurred within the results. The first subsets
of results which concentrate on the enhancement to the existing data model are evaluated
first. Fig 5.10 shows a line chart depicting the spread of the results.
102
Enhance Data Model - Experiment 3
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
user 1 user 2 user 3 user 4 user 5 user 6 user 7 user 8 user 9 user 10
Users
Que
stio
ns
Q3
Q5
Q7
Q9
Fig 5.10
As mentioned earlier, the results for this section are positive and there is very little
deviation between users. Users found it easy to both find and add data and agreed that
updating the model was a lot simpler using the prototype rather than the classic 2D
approach. There were little deviation between results and no exceptions so overall this
section of the experiment was a success
The second subset of results, which refers to the usability of the tool, is now evaluated.
Fig 5.11 shows a line chart depicting the spread of results.
103
Usability - Experiment 3
0
1
2
3
4
5
6
user 1 user 2 user 3 user 4 user 5 user 6 user 7 user 8 user 9 user 10
Users
Que
stio
ns Q2
Q6
Q10
Fig 5.11
In general this section was successful as well. Users generally were positive in their
feedback and found it easy to both use the tool to add new data as well as to navigate
around existing data. However, question six received negative feedback for 40% of users.
As stated earlier, the assumption in this experiment is that users are now familiar with the
tool and no longer have as steep a learning curve. The consensus amongst these users was
that there was no way to set a home state on the data model which could be returned to
whenever a user wished. As a result they had to back track their navigation to return to
certain sections. On analysis, it was decided that rather than been an issue with the
prototype this was more of an enhancement to further improve the navigation.
5.3.3. Interpretation of Results
This result provides much evidence to support the hypothesis. One of the main goals
outlined in the hypothesis was that incorporating data visualization techniques into a 3D
environment would simplify data models, making them easier to use and navigate. The
104
perfect example of when a user needs to navigate within a data model is when they need
to enhance it. By spreading the data around a 3D space it was less cluttered and so easier
to read and understand. A cluttered model was tidied up further by giving the user the
ability to hide and show relationships and attributes so they could concentrate on only
data they were interested in. Incorporating some spatial navigation techniques allowed
the user to easily find specific data they were looking for, which simplified updating the
model. The positive feedback showed that the 3D approach and these data visualisation
techniques greatly improved the readability and intuitiveness of the model. The one
criticism with the prototype was that each time a schema was loaded; its entities or
bubbles appeared in a different position. This relates with the navigation drawback
discussed below.
Although the users gave the navigation in general positive feedback, they would like to
have the ability to save the model in certain states when they are working on a subset of
data and be able to quickly return to this state. This ties in to the ability to save the data
model in a certain state and to return to this state next time the data mode is loaded. This
is not necessarily a problem with the 3D approach but an enhancement request to include
more functionality which is discussed in greater detail in Chapter 6.
5.4. Experiment 4 – Find Table Information
As outlined in section 4.6, the goal of this experiment was to assess how easy it was to
find data using the prototype. Users were asked to find specific pieces of data in a model
they had never seen before.
Similar to the previous two experiments, this experiment had a direct impact on proving
the hypothesis. The third key use of a data model is displaying data in an easy to read
format while also been easy to find. In their simplest form, data models are snapshots of
data bases which tell the user where certain data is stored. Historically, complex models
are very hard to read due to the amount of space they take up and the amount of data they
hold. The aim of this experiment was to show that data could be stored more intuitively
105
using a 3D system and accessed more easily using more modern data visualization
techniques
5.4.1. User Feedback
This section documents the average feedback obtained for the questions outlined in
Section 4.7. These results are then analyzed and interpreted in relation to the hypothesis.
Fig 5.12 shows a table of all the results.
Questionsuser 1
user 2
user 3
user 4
user 5
user 6
user 7
user 8
user 9
user 10
Q1 4 4 5 4 4 4 4 5 4 4Q2 4 4 4 5 5 4 4 5 4 4Q3 4 3 4 5 5 3 5 4 4 4Q4 1 2 2 1 2 1 2 1 1 3Q5 3 3 3 3 3 3 3 3 3 3Q6 3 4 4 2 2 3 4 2 2 3Q7 3 3 3 3 3 3 3 3 3 3Q8 4 4 5 4 5 5 4 5 5 5Q9 4 4 4 5 5 3 5 4 4 4Q10 4 5 3 4 4 4 5 4 4 4
Fig 5.12
These results are then plotted into a line chart in Fig 5.13 for a better visual
representation of the feedback.
106
Experiment 4
0
1
2
3
4
5
6
user 1 user 2 user 3 user 4 user 5 user 6 user 7 user 8 user 9 user 10
Users
Que
stio
ns
Q1Q2
Q3Q4
Q5Q6Q7
Q8Q9
Q10
Fig 5.13
Simplifying the process of finding data by using 3D spatial navigation techniques to
navigate around 3D representations of tables was the goal of this experiment. This
experiment aimed to find if transferring a data model to 3D space made it more readable
and easier to navigate. Usability analysis was also conducted with the assumption that
there would be no learning curve as users should be very familiar with the tool at this
stage.
Most of the results above were expected based on the results of the previous experiments.
Users already had had a lot of exposure to the tool so it wasn’t expected that their results
would dramatically change. Usability ties into the main goal of this experiment. The
process of how the tool renders the 3D space and executes the 3D spatial algorithms is
intertwined with how the tool interacts with the user so unlike the previous two
experiments; this experiment is only interested in one subset of the results.
107
3. I found it easy to find data in the model
4. This data model is a lot easier to read in 2D format
9. It was a lot easier to find data in the 3D version of the data model
10. I found it easy to navigate around the model
The only exception out of the navigation results was with questions six. As this was
discussed in detail in the previous section on experiment three, it is not been taken into
consideration for this experiment. These results basically depict how easily and quickly
the user was able to find some specified data in the data model. There was little deviation
in the response to these questions with the majority of users giving positive feedback.
This suggests that the experiment was a success but this is discussed in greater detail in
the next section
5.4.2. Trends & Exceptions
This section discusses and plots the general trends extracted from the results. It also
discusses and dissects any exceptions which occurred within the results. A subset of
results is evaluated which concentrate on the questions associated with navigation and
retrieval of data. Fig 5.14 shows a line chart depicting the spread of the results.
108
Retrieve Data & Usability - Experiment 4
0
1
2
3
4
5
6
user 1 user 2 user 3 user 4 user 5 user 6 user 7 user 8 user 9 user 10
Users
Que
stio
ns
Q3
Q4Q9Q10
Fig 5.14
As expected, based on results of previous experiments, this experiment was a success.
90% - 100% of users gave positive to very positive feedback for all these criteria. They
found it a lot quicker to navigate through data and to find specific data on the prototype.
The only exception is with user three on question three. This is similar to both
experiments one and two but will be discussed in more detail in the next section.
5.4.3. Interpretation of Results
The results above show that, in general, the majority of users found that depicting a
model in 3D space and having the ability to easily navigate around this space, increased
both the simplicity of the model and made it a lot more intuitive and easier to work with.
This affirms part of the hypothesis which states that incorporating a 3D approach as well
as using modern data visualization techniques can improve the usability of data models
and make them more intuitive to a greater audience.
109
As mentioned in experiment one, user three comes from a non technical background and
has no prior experience with either data modelling or database design methodologies. As
a result, the user found some of the concepts hard to grasp. It was stated that learning
curve would not be taken into consideration in this experiment. However, as the user still
marked the prototype as been easier to find data in, the experiment will be deemed a
success and the exception overlooked.
The one extra comment made by users is that it could be hard to distinguish relationships
when an entity had multiple relationships as all connecting lines converged into the
centre of the bubble. An improvement on this would be to have different relationship
lines converge on different parts of the bubble. This is discussed in greater detail in the
future work section of Chapter 6.
110
6. Conclusions and Future Work
6.1. Conclusions
This work investigated the effect of incorporating 3D modelling and data visualization
techniques with current data modelling methodologies. Primarily, the research focused on
ER and Object models.
The first experiment acted as an acid test for the suitability of using a 3D approach to
data modelling. A very simple data model was rendered in the prototype developed to
implement this new 3D approach. The goal of the experiment was to familiarise users
with the new methodology and data visualization functionality available in the prototype
and to not disprove the hypothesis. It was shown that users found the 3D rendering of the
tables to be very easy to use and that the 3D spatial navigation techniques used to
navigate around the data was effective and user friendly. Users found the navigation
functionality in the prototype to be very intuitive and preferred it to navigating data in a
comparable 2D model. However, there was no obvious improvement seen from the 3D
version of the data over the 2D version. Although users found the new approach very
usable it was no easier to read than the 2D model. This was expected for such a simple
model.
In the second experiment users were given a description of a system and asked to create a
model to support this system. This was a more complex example and so a better
measurement of the improvement experienced with the 3D approach. In general users
found it very easy to create and add data to the data model. A majority of users found it
easier to add data with the tool than using a traditional modelling approach. However,
one common observation among users was that although it was very easy to create tables
and populate them, there was no efficient method to normalise tables. This was
something they felt they could do more effectively using the old approach.
111
Users were also asked to load another user’s solution into the prototype to see how
intuitive they found it. The navigation and manipulation of the data model again scored
high here. Users found it a lot easier to read the data in the tool than in the comparable
2D format. The general consensus was that the model was less cluttered and more
readable in the prototype.
The third experiment asked users to enhance the model they created in experiment two to
support a more complex system. The complexity of the model increased further in this
experiment so the results were useful to ascertain if the 3D methodology did in fact
simplify complex models. Users found the model in the tool much simpler to manipulate
and update than in a comparable 2D approach. The ability to hide certain data and
relationships made the model clearer and easier to work with.
Users again preferred the navigation approach in the prototype to a 2D version. They
were able to view the model in it’s entirety but also zoom into certain sections to perform
their updates. They were then able to view how the updates affected the overall model by
zooming out again. Although a very simple thing, this ability made the model much more
usable and intuitive.
In experiment four, users were asked to load a relatively complex data model into the
data model and to find some pre-defined data elements. The goal of this experiment was
to see how a user managed to work with a complex data model which they were not
familiar with. The results here were compared to the results in the previous experiment to
see if they deviated at all. It was interesting to see that in general, as users became more
familiar with the system, the results got more positive. Users found the model very easy
to navigate through and in general had no issues finding the data required using the 3D
approach
In summary this work investigated the following hypothesis
H1. Current data modelling approaches can be improved by adopting a 3D approach
112
H2. The use of modern data visualization techniques can greatly improve the usability
of data models, making them more accessible to a broader audience.
H3 A combination of a 3D modelling approach with some data visualization
techniques could greatly simplify the modelling of a complex system
Through this it was shown that improvements to data modelling can definitely be
obtained by using a 3D approach and that the use of data visualization techniques also
improved the usability of the models rendered. The complexity of
6.2. Future Work
There are a number of possible and interesting extensions to this work. The first would be
to add some more key functionality to the prototype. One aspect of negative feedback
which was common among users was that the tool didn’t have the ability to easily
normalize a table. A second piece of functionality requested was the ability to save the
data model in certain states. Users wanted to concentrate on specific aspects of the data
model and to be able to load the model up in this state. Personalisation is the third piece
of functionality which would greatly enhance the tool. This would allow users to define
what colour systems they wanted to use in the tool and how they wanted the data
displayed
From the perspective of the 3D modelling methodology there are a lot of enhancements
which could be made. For this research only some key data modelling techniques were
incorporated into the solution. Adding more concepts as multiplicity would be a logical
next step. Also researching and experimenting with other methods of displaying keys and
relationships to see if any are more suited to the 3D approach
113
114
References
[1] Hay, David C. (Oct 1999) A Comparison of Data Modelling Techniques Retrieved Oct 24th 2009 from, http://www.essentialstrategies.com/publications/modeling/compare.htm
[2] Spradley, J.P. (1979). The ethnographic interview. New York: Holt, Rinehart, and Winston.
[3] Litwin, Paul (mid 1990s) Fundamentals of Relational Database Design, Microsoft TechEd Conference, Retrieved Oct 30th from http://www.deeptraining.com/litwin/dbdesign/FundamentalsOfRelationalDatabaseDesign.aspx
[4] Microsoft (2009) Entity Data Model Relationships, MicrosoftRetrieved Oct 31st from http://msdn.microsoft.com/en-us/library/bb399189.aspx
[5] GeekInterview (2005), What is Data Cardinality, GeekInterviewRetrieved Nov 7th from http://www.geekinterview.com/kb/Data-Cardinality.html
[6] Hewett, Baecker, Card, Carey, Gasen, Mantei, Perlman, Strong and Verplank (2009) Human-Computer Interaction, ACM SIGCHI Curricula for Human-Computer Interaction, Retrieved Nov 12th 2009 from http://old.sigchi.org/cdg/cdg2.html
[7] Greenberg, Saul (2001), Map of Human Computer Interaction, Department of Computer Science - University of Calgary, Retrieved Nov 12th 2009 from http://pages.cpsc.ucalgary.ca/~saul/hci_topics/powerpoint_presentations/hci_map.ppt
[8] Friendly, Michael (2009) Milestones in the history of thematic cartography, statistical graphics, and data visualization, Retrieved Nov 15th 2009 from http://www.math.yorku.ca/SCS/Gallery/milestone/milestone.pdf
[9] Friendly, Michael (2001), Gallery of Data Visualization, Retrieved Nov 15th 2009 from http://www.math.yorku.ca/SCS/Gallery/
[10] Adams, Chris (2009), What is Ergonomics, About.com GuideRetrieved Nov 18th fromhttp://ergonomics.about.com/od/ergonomicbasics/a/ergo101.htm
[11] Tukey, John W. (1988) The Collected Works of John W. Tukey. Belmont, CA: Wadsworth Inc.
[12] Few, Stephen (2009), Visualizing Change: An Innovation in Time-Series Analysis, SAS Institute Inc. White Paper retrieved Nov 20th 2009 from http://www.jmp.com/blind/whitepapers/wp_visualizing_change_103272.pdf
[13] Nooface (June 2009), Showcase of 3D Data Visualization TechniquesRetrieved Nov 20th 2009 from http://nooface.net/article.pl?sid=06/06/12/2221255
[14] Duggal, Vijay (2009) The World Wide Web Virtual Library: CADRetrieved Nov 21st from http://www.caddprimer.com/library/
[15] McNeel (2007), What is NURBS, RhinocerosRetrieved Nov 21st from http://www.rhino3d.com/nurbs.htm
115
[16] Altmann, Markus (1997), About Nonuniform Rational B-Splines – NURBS, Worchester Polytechnic Institute – Computer Science Retrieved Nov 21st 2009 from http://web.cs.wpi.edu/~matt/courses/cs563/talks/nurbs.html
[17] McGregor, Nicolas (April 2009) What is 3D Spline Modelling and Patch Modelling, Suite101, Retrieved Nov 21st 2009 from http://computersoftware.suite101.com/article.cfm/what_is_3d_spline_modeling_and_patch_modeling
[18] 2010 International Conference on Intelligent User Interfaces (2009)Retrieved on Nov 21st 2009 from http://www.iuiconf.org/about.html
[19] Greenstein, Daniel I., Thorin, Suzanne Elizabeth. (2002) The Digital Library: A Biography, Digital Library Federation Accessed Nov 22nd 2009
[20] Google (2009), Google SketchUp Features, Accessed on Nov 21st 2009 from http://sketchup.google.com/product/features.html
[21] Bunyan, Jason (October 2009) KartOO: Mapping Search Intuitively – Insider Profile. Accessed Jan 2nd 2010http://www.digitalmediabuzz.com/2009/10/kartoo-mapping-search/
[22] Tominski, Christian, Abello, James, Van Ham, Frank, Schumann, Heidrun Fisheye Tree Views and Lenses for Graph Visualization. Accessed Jan 7th 2009http://www.research.ibm.com/visual/papers/iv06_v2.pdf
[23] Janert, Phillip, Practical database design, Part 2 (2003)Accessed Jan 8th 2010http://www.ibm.com/developerworks/web/library/wa-dbdsgn2.html
[24] Ambler, Scott W, The Object-Relational Impedance Mismatch (2002)Accessed Jan 12th 2010http://www.agiledata.org/essays/impedanceMismatch.html
[25] Burbeck, Steve, Applications Programming in Smalltalk-80(TM): How to use Model-View-Controller (MVC)Accessed Feb 2nd 2010http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html
[26] Hall, Cliff, pure mvc Framework Goals & BenefitsAccessed Feb 2nd 2010http://puremvc.org/pages/docs/current/PureMVC_Framework_Goals_and_Benefits.pdf
[27] Ambler, Scott W, Techniques for Successful Evolutionary/Agile Database DevelopmentAccessed Oct 26th 2009http://www.agiledata.org/essays/dataModeling101.html
[28] Chen, Peter Pin-Shan, The entity-relationship model – towards a unified view of data Accessed Oct 25th 2009 fromhttp://portal.acm.org/citation.cfm?id=320440
[29] Kent, William, A Simple Guide to Five Normal Forms in Relational Database Theory, Accessed Oct 3rd 2009 fromhttp://www.bkent.net/Doc/simple5.htm#label4
116
[30] Galyean, Tinsley A, Hughes, John F, Sculpting: an interactive volumetric modeling technique Accessed Dec 23rd 2009 fromhttp://portal.acm.org/citation.cfm?id=127719.122747
[31] Helman, Dean, Objective Toolkit Pro whitepaper Accessed Mar 12th 2010 fromhttp://ootips.org/mvc-pattern.html
List of Figures1.1 http://www.scottgu.com/blogposts/linq4/step0.jpg1.2 http://rscott.myweb.uga.edu/XAS/XASTutChem3D010.jpg
2.1 http://msdn.microsoft.com/en-us/library/bb399189.aspx 2.2 http://www.research.ibm.com/visual/papers/iv06_v2.pdf2.3 http://www.research.ibm.com/visual/papers/iv06_v2.pdf2.4 http://www.research.ibm.com/visual/papers/iv06_v2.pdf2.5 http://www.research.ibm.com/visual/papers/iv06_v2.pdf2.6 http://www.vsg3d.com/vsg_prod_avizo_overview.php2.7 http://www.rhino3.de/design/prototyping/2.8 http://www.lightwiki.com/images/6/6f/SplineModel3.gif2.9 http://visibuild3d.com/images/button_immersive3d1.png2.10 http://www.blender.org/typo3temp/pics/9a1580be01.jpg2.11 http://www.dehash.com/?p=48 2.12 http://ww5.kartoo.com/
3.1 Bubble3.2 Prototype Modelling Stage3.3 2D Representation of Bubble3.4 http://www.pnp-software.com/eodisp/documentation/developerManuals/
guiArchitecture.html 3.5 Prototype System Diagram3.6 Prototype Wireframe3.7 Entity Relationships3.8 Modelling Stage Class Diagram3.9 Prototype Menu3.10 Menu Class Diagram3.11 Database & Prototype Interaction3.12 Valid User Check3.13 Database Design3.14 Initialization Class Diagram3.15 Initialization Sequence Diagram3.15 Entity Class Diagram3.16 Entity Creation Sequence Diagram3.17 Navigation Class Diagram3.18 Navigation Sequence Diagram3.19 Schema & Entity Class Diagram - Method 1
117
3.20 Schema & Entity Sequence Diagram - Method 13.21 Schema & Entity Class Diagram - Method 23.22 Schema & Entity Sequence Diagram - Method 23.23 Schema Retrieval Class Diagram3.24 Schema Retrieval Sequence Diagram3.25 Sphere Construction3.26 Create Relationships3.27 PHP Error Handler3.28 Prototype Server Exception Handler3.29 XML Parser - Part 13.30 XML Parser - Part 23.31 Entity Point3.32 Matrix Transformation Algorithm3.33 Update Entity Position3.34 Scale Entity
4.1 Case Study4.2 Simple Data Model4.3 Complex Data Model
5.1 Experiment 1 Table of Results5.2 Experiment 1 Line Chart5.3 Experiment 1 Usability Results5.4 Experiment 2 Table of Results5.5 Experiment 2 Line Chart5.6 Experiment 2 Create Data Model Results5.7 Experiment 2 Usability Results5.8 Experiment 3 Table of Results5.9 Experiment 3 Line Chart5.10 Experiment 3 Enhance Data Model Results5.11 Experiment 3 Usability Results5.12 Experiment 4 Table of Results5.13 Experiment 4 Line Chart5.14 Experiment 4 Retrieve Data & Usability Results
Technologies & External ResourcesProject Website: http://compsoc.nuigalway.ie/~derm116/Boilgeog/ Flash: http://get.adobe.com/flashplayer/otherversions/ Flash Tutorials: http://www.gotoandlearn.com/ PHP: http://www.php.net/ phpMyAdmin: http://www.phpmyadmin.net/home_page/index.php MySQL: http://www.mysql.com/ pureMVC: http://www.puremvc.org/ zSorter: http://blog.theflashblog.com/?p=470
118
3D Sphere: http://www.flashandmath.com/flashcs4/spheregallery/index.html Data modelling tutorial: http://www.getahead.uk.com/gwbadat.htm PaperVision3D: http://blog.papervision3d.orgAway3D: http://www.away3d.com/
119