A collection of information technology and consulting knowledge
Category: Technical Design
A technical specification describes the minute detail of either all or specific parts of a design, such as:
the signature of an interface, including all data types/structures required (input data types, output data types, exceptions);
detailed class models including all methods, attributes, dependencies and associations;
the specific algorithms that a component employs and how they work; and
physical data models including attributes and types of each entity/data type.
In denodo associations follow the same concept as modeling
tools, which can be described as an ‘on-demand join.’
Should Associations Be Created In the Denodo Model?
You don’t necessarily need to define an Association at every
level; usually, the best practice is to apply associations at the following
On final views published for data consumers,
indicating relationships between related views; Especially, on published web
On the component views below, any derived view
that brings together disparate (dissimilar) data sources. The associations should be defined as
Referential Constraints whenever appropriate to aid the optimization engine.
On the component views below, any derived view
that joins a “Base View from Query” with standard views, since Base
Views from Query cannot be rewritten by the denodo optimization engine. Often Base Views from Query create
These best practices should cover the majority scenarios;
beyond these guidelines, it is best to take an ad-hoc approach to create
Associations when you see a specific performance/optimization.
Are Associations important in Denodo?
In a nutshell, associations performance and the efficiency
of the denodo execution optimizer along with other model metadata, such as:
Personas and roles are
user modeling approaches that are applied in the early stages of system
development or redesign. They drive the design decision and allows programmers
and designers to place everyday user needs at the forefront of their system
development journey in a user-centered design approach.
Personas and user roles
help improve the quality of user experience when working with products that
require a significant amount of user interaction. But there is a distinct
difference between technology personas vs. roles. What then exactly is a
persona? What are user roles in system development? And, how does persona
differ from user roles?
Let’s see how these two
distinct, yet often confused, user models fit in a holistic user-centered
design process and how you can leverage them to identify valuable product
Vs. Roles – The Most Relevant Way to Describe Users
In software development,
a user role describes the relationship between a user type and a software tool.
It is generally the user’s responsibility when using a system or the specific
behavior of a user who is participating in a business process. Think of roles
as the umbrella, homogeneous constructs of the users of a particular system.
For instance, in an accounting system, you can have roles such as accountant,
cashier, and so forth.
However, by merely using
roles, system developers, designers, and testers do not have sufficient
information to conclusively make critical UX decisions that would make the
software more user-centric, and more appealing to its target users.
This lack of
understanding of the user community has led to the need for teams to move
beyond role-based requirements and focus more on subsets of the system users.
User roles can be refined further by creating “user stand-ins,” known as
personas. By using personas, developers and designers can move closer to the
needs and preferences of the user in a more profound manner than they would by
merely relying on user roles.
In product development,
user personas are an archetype of a fictitious user that represents a specific
group of your typical everyday users. First introduced by Alan Cooper, personas
help the development team to clearly understand the context in which the ideal
customer interacts with a software/system and helps guide the design decision
provide team members with a name, a face, and a description for each user role.
By using personas, you’re typically personalizing the user roles, and by so
doing, you end up creating a lasting impression on the entire team. Through
personas, team members can ask questions about the users.
The Benefits of
Persona development has
several benefits, including:
They help team members
have a consistent understanding of the user group.
stakeholders with an opportunity to discuss the critical features of a system
Personas help designers
to develop user-centric products that have functions and features that the
market already demands.
A persona helps to
create more empathy and a better understanding of the person that will be using
the end product. This way, the developers can design the product with the
actual user needs in mind.
Personas can help
predict the needs, behaviors, and possible reactions of the users to the
What Makes Up a
Once you’ve identified
user roles that are relevant to your product, you’ll need to create personas
for each. A well-defined persona should ideally take into consideration the
needs, goals, and observed behaviors of your target audience. This will
influence the features and design elements you choose for your system.
The user persona should
encompass all the critical details about your ideal user and should be
presented in a memorable way that everyone in the team can identify with and
understand. It should contain four critical pieces of information.
1. The header
The header aid in
improving memorability and creating a connection between the design team and
the user. The header should include:
A fictional name
An image, avatar or a
description/quote that best describes the persona as it relates to the product.
Unlike the name and
image, which might be fictitious, the demographic profile includes factual
details about the ideal user. The demographic profile includes:
Age, gender, education, ethnicity, persona group, and family status
Occupation, work experience, and income level.
User environment. It
represents the social, physical, and technological context of the user. It
answers questions like: What devices do the user have? Do they interact with
other people? How do they spend their time?
Attitudes, motivations, interests, and user pain points.
3. End Goal(s)
End goals help answer
the questions: What problems or needs will the product solution to the user?
What are the motivating factors that inspire the user’s actions?
This is a narrative that
describes how the ideal user would interact with your product in real-life to
achieve their end goals. It should explain the when, the where, and the how.
For a truly successful
user-centered design approach, system development teams should use personas to
provide simple descriptions of key user roles. While a distinct difference
exists in technology personas vs. roles, design teams should use the two
user-centered design tools throughout the project to decide and evaluate the
functionality of their end product. This way, they can deliver a useful and
usable solution to their target market.
A foreign Key (FK) is a constraint that references the unique primary key (PK) of another table.
Facts About Foreign Keys
Foreign Keys act as a cross-reference between tables linking the foreign key (Child record) to the Primary key (parent record) of another table, which establishing a link/relationship between the table keys
Foreign keys are not enforced by all RDBMS
The concept of referential integrity is derived from foreign key theory
Because Foreign keys involve more than one table relationship, their implementation can be more complex than primary keys
A foreign-key constraint implicitly defines an index on the foreign-key column(s) in the child table, however, manually defining a matching index may improve join performance in some database
The SQL, normally, provides the following referential integrity actions for deletions, when enforcing foreign-keys
The deletion of a parent (primary key) record may cause the deletion of corresponding foreign-key records.
Forbids the deletion of a parent (primary key) record, if there are dependent foreign-key records. No Action does not mean to suppress the foreign-key constraint.
The deletion of a parent (primary key) record causes the corresponding foreign-key to be set to null.
The deletion of a record causes the corresponding foreign-keys be set to a default value instead of null upon deletion of a parent (primary key) record
A Composite Primary key is Primary key What a primary key, which is defined by having multiple fields (columns) in it. Like a Primary Key what a composite Primary Key is depends on the database. Essentially a Composite Primary Key:
Is a combination of Fields (columns) which uniquely identifies every row.
Is an index in database systems which use indexes for optimization
Is a type of table constraint
Is applied with a data definition language (DDL) alter command
And may define parent-Child relationship between tables
Microsoft doesn’t provide macro guidance for naming convention, however, sometimes it is useful to have a place to start. Also, there are times when flexibility with naming conventions are necessary. So, here is a quick set of SQL Server naming conventions, which may be helpful if you find yourself working with a customer who doesn’t have an established set of naming convention standards and you need to assemble a set fast.
Basic SQL Server Object Naming Convention Guidance
Each project will have its own schema.
Schema represents the project
First letter of each word in table/Column starts with Uppercase.
Put Underscore(_) between words of table/Column name