- Attribute Hierarchy : Attributes and Attribute Hierarchies (MSDN)
- Discrete Attributes and Contiguous Attributes : Quoted from Introduction to Attribute Discretization (William Pearson) - “ Whenever we work with attributes, we can expect to encounter two general types of values:
- Discrete attributes: Discrete values stand apart distinctly, and have clearly defined logical “boundaries” between themselves. The possible values are naturally discrete for the lion’s share of attributes occurring in the business world.
Example: The Gender attribute, within the Customer dimension of the Adventure Works sample UDM, is (at least for purposes of the sample cube) considered to have only one of two discrete values, female or male. - Contiguous attributes: Contiguous values do not stand apart distinctly, but flow along, as if in a continuous line. Contiguous values, especially within large populations, can have very large numbers of possible values. Information consumers can find it difficult to work effectively and efficiently within such wide ranges of values.
Example: the Vacation Hours attribute, within the Employee dimension of the Adventure Works sample UDM, can have a wide range of possible values, depending upon how many employees are involved, whether there are limits on how many vacation days they can accumulate, and considerations of this nature. The member values are based directly upon the unique values contained within the VacationHours column of the DimEmployee table (with many of the unique values shared among multiple employees). The sheer number of values might make working with them cumbersome for information consumers, if they are simply made available in their existing state. “
Read more : here
- Discrete attributes: Discrete values stand apart distinctly, and have clearly defined logical “boundaries” between themselves. The possible values are naturally discrete for the lion’s share of attributes occurring in the business world.
DotNetting
ASP.NET , C# , SQL Server , Ajax , jQuery , Silverlight , WPF , WCF and many more...
Wednesday, June 16, 2010
SSAS Dimension Attribute Properties
| Reactions: |
Tuesday, June 15, 2010
FaceLight – Silverlight 4 Real-Time Face Detection
Introduction
Demo Application
| Reactions: |
SilverShader – Introduction to Silverlight and WPF Pixel Shaders
Introduction
Demo Application
Read more : here
| Reactions: |
Push and pull - Silverlight Webcam Capturing Details
Read Full Article : here
| Reactions: |
Microsoft Translator client library for Silverlight
- Detect
- GetLanguagesForSpeak
- GetLanguagesForTranslate
- Speak
- Translate
Because this is a service, the wrapper implements the above functions as asynchronous methods, so you will see:
- DetectAsync
- GetLanguagesForSpeakAsync
- GetLanguagesForTranslateAsync
- SpeakAsync
- TranslateAsync
Read more : here
| Reactions: |
Monday, June 14, 2010
Transparent Data Encryption (TDE) in SQL Server 2008
Introduction
As part of the SOX (Sarbanes-Oxley Act) regulatory compliance implementation, one of my banking customers asked me to encrypt their database for an already existing application. It was a business critical web application developed using Visual Studio 2005 (ASP.NET 2.0 framework) and SQL Server 2000 as the backend database. Like any other standard software development project, the delivery schedule for this was also very tight and the client requested that I implement database encryption as quickly as possible, with minimal impact on the existing application. I completed that assignment on time and within budget using Transparent Data Encryption (TDE), a new full database encryption technique introduced in SQL Server 2008. In this article, I will demonstrate the implementation of TDE.
Why Transparent Data Encryption (TDE)
I had to spend 1/3 of the entire project time in feasibility study and chose the best technique for encrypting the existing database from the available options.
SQL server 2000 doesn't provide advance encryption features. Developers need to write extended stored procedures to implement encryption but for this project that was not feasible as modification of all the existing stored procedures would have taken much more time than the client's specified timeframe. There are few third party tools available in the market like DbEncrypt. Using these tools developers can implement encryption for SQL server 2000 databases, but my client didn't agree to spending the extra money for a DbEncrypt license.
My customer was already using SQL server 2005, so I planned to migrate the already existing SQL Server 2000 database to SQL Server 2005 and implement encryption on top of new 2005 databases. However, to implement data or cell level encryption in Microsoft SQL Server 2005, all table column data type must be varbinary, which means I needed to change all existing table structures and modify column data types to varbinary. In addition, there are few drawbacks of SQL Server 2005 data encryption:
- Ranged and equality searches are not supported in SQL Server 2005 on the encrypted data values.
- ASP.NET web application performance will be very slow while querying encrypted data because data will be decrypted before sending to front end. Also creating index or using foreign keys often do not work properly with cell-level or column-level encryption.
- Data backup taken using SQL Server 2005 "Backup" command will not have encryption. Backup data will be in readable format. That means a high data security violation.
Finally, I completed the assignment by implementing TDE. Full database level encryption is first introduced in SQL Server 2008 using TDE. TDE is the best choice for bulk encryption and as a part of the regulatory compliance implementation. Microsoft has designed TDE to provide protection for the entire database without affecting existing applications. After TDE implementation, any backup taken in tape will be as secure as the source database. Without an access key, tape data can't be used. I convinced my customer to migrate the existing SQL Server 2000 database to SQL Server 2008 and implement TDE on top of new SQL Server 2008.
Read Full Article -> here
Hope this helps !!!
| Reactions: |
Top 13 SQL Server Mistakes and Missteps – #10 Default Database Autogrowth Settings
By default, new databases are created with the following basic file settings:
- Data File: 2 MB 1 MB unrestricted growth
- Log File 1Mb 10% unrestricted growth
Just exactly why is this bad?
- It will assuredly increase the frequency at which files will grow automatically… A transaction log file, if configured for autogrowth, will expand when it does not have enough free space to record a transaction. This could be due to a large transaction or cumulative transactions where the log is not truncated due to a combination of the recovery model and transaction log backup schedule.
- It holds up transaction processing… While the log file is expanded, the transaction that is causing the growth to occur is in a wait state, as is any other transaction that would need to write to the transaction log. This will increase the time required to process and commit the transaction(s) and may result in a timeout to the end user depending upon the connection settings for any affected requests.
- It causes external file fragmentation… Repeated file growth (automatic or manual) can result in external file fragmentation which in-turn affects performance negatively. SQL Server loves sequential reads and writes. A fragmented log file can result in an increase in non-sequential writes; a fragmented data file or index file will result in more non-sequential reads. This is because as SQL Server is required to increase the file size, it does so scattered on the disk as space allows. A logical file with bits all over the disk.
- Instant File Initialization is only applicable to Data Files… Instant file initialization exists in SQL Server 2005 and newer. This alleviates the issue with a file being inaccessible while it is being expanded. However, this only applies to data files – log files are not affected by instant initialization.
Read Full Article - > here
Hope this helps !!!
| Reactions: |