Grounding.co.za

Technology information for IT specialists
Welcome to Grounding.co.za Sign in | Join | Help
in Search

Tech Talk with Brett Maytom

June 2007 - Posts

  • Sandcastle - MSDN style documents

    Sandcastle is a new product that Microsoft is bringing out that will help you generate MSDN style documents from your code.  It is currently being used internally in Microsoft to generate the MSDN documents.  At the moment the product is in Community Test Preview (CTP).  It supports all the .NET 2 features such as generics.

    To read more and download Sandcastle go to http://msdn2.microsoft.com/en-us/vstudio/bb608422.aspx.  You will also need the help compiler which you can download here http://msdn2.microsoft.com/en-us/library/ms669985.aspx

  • Embracing a new era of web applications

    The web has become part of ones every day life and web sites like google have become verbs in every day language.  It even hear slang such as "I'll ping you later" and "blog it" part of general communications.   E-mail is so critical these days that one feels rather helpless when the mail servers go offline.  This got me thinking about where are we headed to, what will the web be like in five or ten years from now.   This is rather scary if I look back five or ten years and see what has changed.

    As far a business applications go, the take-on of web technology has been slow. Companies have invested huge amounts in the client server technologies.  The tool sets used to create web based solutions a few years back, work but they had many performance issues.  ASP.NET with the 1.0 and 1.1 framework opened up many developers eyes and a gradual change in UI started.  The 2.0 framework stirred showed off the ease of development with a large drive on web services, XML and interoperability. 

    The older technologies are now becoming obsolete and many solutions are no longer acceptable.  Business computing demands have quadrupled as has the volume of data processed.  Take a look at the current drive in companies with Microsoft Office SharePoint Portal (MOSS), the product is selling fast,  I can see this in the training volumes.  Other technologies such as Office 2007, BizTalk 2006 R2, SQL 2008 (Katmai) and Windows Server 2008 (Longhorn) are gearing up for SharePoint. 

    The time for the web applications is now!  Companies are ready for web technologies.  Communication backbones are constantly being improved and prices decreased (well perhaps not in South Africa, It will wrong not to take a dig at our Telco :P).  The man on the street has embraced and uses the technology.  A technical explosion is about to hit.

    The next few years

    In the next five years companies will implement portals using Sharpoint, move to Office 2007 and upgrade to SQL 2007.  There will be a big drive on WebPart development as to publish product user interfaces on the intranet.  The drive on Service Orientated Architecture will be demanded and web services will sprout up.  User understanding and day-to-day use will become more reliant on web based technologies, mail, collaboration and searching using corporate search engines.

    UI Workflow, Business workflow and integration workflow will build a solid foundation for SOA applications.  Web services will evolve to a more reliable model with easier transaction handling.

    Database technologies such as SQL server will move more and more to an object database as most development languages today use object orientation, the serialization and demoralization to these objects will become simple declarative statements.  Data Access Control Layers are of the past and binding of "class" to data entity will be implicit.  This can already be seen in Orcas and Katmai.

    Ajax although been around for some time is now solving many web postback problems and providing for a richer user experience in the browser.  This technology will be enhanced, yet it will become more invisible to programmers as components will hide it.

    Within the next 10 years

    Personalization. Web content will become more prevalent and users will demand customization due to the volume of applications.   They will want to see content in themes of their choice, where they want to and when they want to.

    Search technology.  We are going to be bombarded with information and search filtering will become necessary.  Concepts like keep track of your interest areas will be used to limit search results.  Search engine technology will be pushed to its limits and interesting innovations will be made in this field.  Spam filtering and advertising filtering will become common in many search engines.

    Smart client.  Products such as Silverlight will introduce the next age of web content applications as it brings back UI control that we once had in forms based applications.  Browsers will process and cache information more readily to prevent round tripping. This has been overdue for some time now and application architects will feel they have control back.  Welcome to the smart client in a browser using a language of your choice, e.g. C#, VB, Python and even the new kid on the block Ruby.  Ajax is included an will be used extensively.

    Multimedia such as audio, video and 3D graphics will become every day content.  The graphic industry be challenged to always better present product and to catch a surfers eye.

    Business services and applications will now be published on the web and hosted by Application Service Providers (ASP).  These ASPs will start renting software out on volume basis instead of traditional software purchasing.

    Telecommunication will be constantly upgraded as the demands will be higher and higher with the average user moving a few gigabytes per day will the norm. These telecommunication companies will be under pressure to deliver stable and reliable networks at lower costs and SLA's are going to have to be put on the table.

    Processor power.  I feel that processor power will no longer be a bottle neck, but communication and bandwidth will be.

    Company portals will become more common with applications hosted within the portal, everyone competing for a bit of the pie.

    Communities Individuals will start moving to online communities such as online gaming, blogging communities, discussion communities and chat forums and instant messaging.  Communities are going to span cultures, countries and language.  A lot of socializing will occur over the Internet.  Every second person will be blogging, or establishing a family portal with pictures and events for everyone to see. 

    Security Spamming, phishing and online scams is going to be a challenge as security will evolve.  The down side is that the scams will also evolve and a never ending cycle will occur.

    Consumer market.  The market place for consumer goods is going to increase to make life more convenient. Online banking, transitioning will be mandatory for every company.   Shopping for monthly groceries will be at a high to small things as ordering take-out and renting a movie.

    Media. As bandwidth increases so will media broadcasting, such as online radio, television and movie hire will dominate social live.  Ones TV will simply be connected to the Internet through a video or audio stream.  Your remote control will be a mini keyboard allowing you to change channel.

    Integration.  Big brother will be watching even closer and more legislation will be enforceable.

    Advertising. Online advertising will be all over the place and people will also become tired of it.  A new industry of advertising blockers will start and filtering applications will be big.

    Voice. The technology has been growing for years and will start emerging later down the line.

    Summarizing

    The web is going to be in everyone's face all the time through socializing, work, collaboration and retail.  There won't be a day that goes by without been connected to the Internet.

    I look forward to ten years from now when I read my own blog again. 

    I look forward to reading your comments and ideas

    Posted Jun 29 2007, 05:39 AM by Brett with no comments
    Filed under:
  • Splitting business and development analysis

    31.1% of projects will be cancelled before they complete

    52.7% of projects will overspend by 189%

    16.2% of projects complete on time and within budget.

    image

    Those are some scary figures from the Standish Group's chaos report.

    Reasons behind the failures

    There are many reasons for software failure, and in most cases it is a combination of several reasons, this list indicates common reasons and by no means complete.

    • Lack of understanding users’ needs
    • Ill defined project scope
    • Poor project management
    • Lack of management involvement
    • Poor requirements and specifications
    • Poor management: Planning, tracking and control.
    • Unrealistic or unarticulated project goals
    • Inaccurate estimates of needed resources
    • Badly defined system requirements
    • Unmanaged risks
    • Poor communication among customers, developers, and users
    • Use of immature and incorrect technology
    • Inability to handle the project's complexity
    • Sloppy development practices
    • Corporate politics
    • Commercial pressures

    My take on this

    In many of the projects I have been involved in or consulted on, I can see some of the above points come to play, however two I have noticed a few common trends.  I do not know if it is a South African development culture or a general world wide problem.  These extra reasons are

    • Undefined business processes
    • Power struggles  (hey I know :P)
    • Scope creep (aka Poor project management)
    • General lack of business knowledge from users
    • Poor business analysis and functional specifications
    • Poor documentation

    Project startup problems

    No matter what SDLC approach you take there is a common pattern of activities we take.  These activities may be very formal or informal, documented formally or on the back of match box.  There approaches could vary from a waterfall, iterative, rapid, agile or many others and even some hybrid combination.

    image

    The part that bothers me the most is the little block of analysis, the common take on it from most approaches indicates this where requirements from users should be dealt with.  These include

    • Requirements
    • Use cases
    • Business processes
    • Artifact identification
    • Rules, regulations and corporate governance
    • Possible negotiation on perceived new system user interface and workflows
    • object modeling (ORM models)
    • i.e. find out what the user wants, how, when and come up with some ideas.

    My experiences show that the users are faced with some business problem that the do not quite understand and believe a system can help them out.  There is some business challenge that IT must help bail them out of and figure out.  Ideas start flowing and solutions thought out and during development and testing, the truth normally gets revealed, this is not going to sort the problem out. BANG!!! SCOPE CREEP, re-engineering and irritation.

    What is happening is that development teams are basing designs on weak business process that are fundamentally flawed and coding this logic into a system.  The initial releases of the system basically automate this flawed business logic, I normally express this as

    "A screwed up business process
    will result in an automated system screw up
    at a much faster rate" 

    Some questions I normally ask which give me a good indication of where the development coming from

    Is there a business problem that a system should solve?  This normally indicates that nobody has a clue on how to solve the problem and are hoping that the "cleaver computer" can do it.  In this situation it is clear stop condition and no system development should be?

    Are there well documented business processes and where are they?  If there is no processes in place, no one really knows what is going on hoping that the "cleaver computer" will define it.  If there are in what level are they, are they up to date and un ambiguous?

    Is the solution in line with the business strategy?  This is highly important as to determine whether it a a strategic, tactical or crisis management need.  Strategic systems are what technical team are looking for. 

    Is this system going to radically streamline processes, open new avenues and financially benefit the business?  If no, explain Return on Investment,  actually that is wrong an you should donate the money to me rather :P

    Who is driving the solution?  Is IT driving a solution into business or is business driving a solution for IT to automate?  IT = cowboys!

    Where do business analysts report to?  If it is within the IT structure, this typically indicates technical people trying to drive business!  Business analysts should have no IT bias and focused on business process engineering and reengineering.  The should involve IT if they feel a system could automate and streamline the process.

    What level is senior management involved and the motivational drive for a new system?  If there is little involvement, there is a problem and caution should be taken on the project.  Is the drive a strategic drive or a crisis management drive?  Avoid crisis management drives as these projects normally fail and waste money.

    Are functional specifications from business technical?  UML, object models and entity relationship diagrams?  Techie pretending to be a business analyst, caution should be taken.

    Business team involvement or a one-(wo)man show?  Make sure there is no power play here and the solution falls in line with strategy?

    The entire analysis phase is wrong and in the wrong place, out of context and the root of all software hell.  The business analysis phase should not be done with a system in mind and without any information technology or development team input.  Business needs to drive the process and solve the business problem.  Once the problem is solved, a system can be developed or procured to assist in automating the process. 

    There are a few core points that business need to address

    • Define the current business processes.
    • Identify where the current process is falling over.
    • Eliminate existing bureaucratic procedures.
    • Identify ownership and chain of responsibilities.
    • Define risks to business and client.
    • Identify scenarios where process will fail and modify processes to accommodate exceptions.
    • Set business service level agreements, timings and escalation patterns.
    • Associate job roles with these processes.
    • Define communication methods.
    • Streamline the process wherein everyone agrees.
    • Identify possible areas for automation through technology.
    • Role play and test these scenarios out.
    • Discard any ambiguity from processes.

    At this point the IT team can start by looking at the technical scope of what needs to be done based on suggestions of automation.  Analysis made on technologies that may assist in the each and every process.  Each and every process can be technically and logically checked and verified.  Discrepancies are passed back to business to resolve before any design commences. Should any technical person not fully understand the business processes, requirements then there is an problem with the definition of the process.

    "If it is hard to understand,
    then it is not clearly defined!" 

    Thus the process looks something like:

    image

    The design phase can now start prototyping front-ends, work flows and following the process, the only difference is now the technical team know what they have to deliver as it is clearly defined.

    Posted Jun 28 2007, 02:35 PM by Brett with 4 comment(s)
    Filed under:
  • C# - Value Type? null?

    Abstract

    In the .NET framework all value types are structures which mean that they are initialized and reside on the stack.  As structs they cannot be set to null and this may create a problem when dealing with databases where we do have nullable fields.

    The code below will not compile

    int x;
    x = null; // This will not compile

    .NET 1 and 1.1 Solution

    With the .NET 1 and 1.1 framework you would have to treat all nullable fields as objects and rely on the boxing and un-boxing mechanism.  This would require you to cast the data into the appropriate type every time you wished to use it.  The code below demonstrates how it was done.

        object x;
        x = reader.GetValue(1);         //GetValue returns an object
        Console.WriteLine((int)x);      //Notice the casting to int

    .NET 2 solution

    With .NET 2, the question mark (suffix) allows you to declare a value type as nullable, example

        int? x;  // Initialised to null

    All value types can be treated as nullable characters.  Digging into the .net 2.0 framework will show you that the ? postfix is actually a generic type that encapsulates the logic of boxing and unboxing. 

    In fact

        int x;
    

    is the same as

        Nullable<int> x;

    Some comments copied from MSDN:

    • Supports a value type that can be assigned a null reference (Nothing in Visual Basic) like a reference type. This class cannot be inherited.
    • A type is said to be nullable if it can be assigned a value or can be assigned a null reference (Nothing in Visual Basic), which means the type has no value whatsoever. Consequently, a nullable type can express a value, or that no value exists. For example, a reference type such as String is nullable, whereas a value type such as Int32 is not. A value type cannot be nullable because it has enough capacity to express only the values appropriate for that type; it does not have the additional capacity required to express a value of null.
    • When a nullable type is boxed, the common language runtime automatically boxes the underlying value of the Nullable object, not the Nullable object itself. That is, if the HasValue property is true, the contents of the Value property is boxed. If the HasValue property is false, a null reference (Nothing in Visual Basic) is boxed. When the underlying value of a nullable type is unboxed, the common language runtime creates a new Nullable structure initialized to the underlying value.

    Proof of concept code

    namespace Brett.POC.NullValueType
    {
        using System;
        using System.Data.SqlClient;
        using System.Data;
    
        class Program
        {
            static void Main(string[] args)
            {
                int? i;
                
                // Initially i will be initialized to null
                // if you attempt to use i before asignment, the compliler will complain that
                // i has not been initialized, thus taking on the characteristic of a common
                // valuetype.
                Console.WriteLine("i is null");
                
                // Initialize i
                i = 10;
                Console.WriteLine("Before add : i={0}", i);
    
                // Call AddFive to proove that it is still a value type
                AddFive(i);            
                Console.WriteLine("After add : i={0}", i);
    
                // Initialize i as null
                i = null;
    
                //Define a connection to a SQL database
                string connectionstring = "Data Source=localhost;Initial Catalog=AdventureWorks;Integrated Security=SSPI";
                using (SqlConnection cn = new SqlConnection(connectionstring))
                {
                    //Create a T-SQL command that will be executed on the SQL conneciton
                    string sql = "SELECT EmployeeID, ManagerID, Title "
                                 + "FROM HumanResources.Employee "
                                 + "WHERE ManagerID IS NULL";
                    using(SqlCommand cmd = new SqlCommand(sql, cn) )
                    {
                        // Establish connection
                        cn.Open();
                        //Execute T-SQL
                        IDataReader reader = cmd.ExecuteReader();
                        //Data back?
                        if( reader != null)
                        {
                            //Loop through all records
                            while( reader.Read() )
                            {
                                int employeeId;     //NOT NULL                            
                                int? managerId;     //NULL
                                string title;       //NOT NULL
    
                                employeeId = reader.GetInt32(0); 
                                //This line checks if it is null and sets manager to null otherwise returns
                                //the manager.
                                managerId = reader.IsDBNull(1) ? (int?)null : reader.GetInt32(1);  
                                title = reader.GetString(2); 
                                
                                Console.WriteLine("{0} {1} {2}", employeeId, managerId, title);
    
                            }
                            //Tidy up
                            reader.Close();
                        }
                        cn.Close();
                    }
                }
            }
    
            //Proving NOT NULL
            static void AddFive(int? no)
            {
                if( no != null )
                    no += 5;
            }
        }
    }
    
    Posted Jun 28 2007, 10:06 AM by Brett with no comments
    Filed under: ,
  • Designing databases - File groups for OLTP

    Abstract

    When creating a typical OLTP database, on a SQL server it is not simply a quick GUI clickity-click.  Some thought needs to go into the creation of file groups.  This initial decision will live through the development, testing and production life span of the system.  Production engineers may loose the ability to provide high availability on the database or may have lengthy backup durations which exceed available backup window times.

    In this blog, I will attempt to describe the usage of file groups.

    The benefits of file groups

    Filegroups in SQL server are wonderfully versatile and have multiple benefits to a database.  These benefits are numerous and discussed below:

    Data aging

    By creating several file groups for current, historical and archived data and the tables created in each file group.  Stored procedures can be written to move the data from current to history to archive on regular intervals. 

    image

     The above diagram has many benefits

    • The current (core) data group only contains data that is current and in use at present thus containing a small volume of records. 
    • The majority of client facing transactions will be aimed at the core tables and as they are small, inserts updates and possible deletes will be fast.  This is due to the fact that indexes will be small.
    • Inactive data that should be kept for record purposes should be moved to the history tables which reside on the history file group.  This should be controlled on a schedule but not too frequent basis.  Once the stored procedures move the data from core to history, they should make the file group read-only to prevent accidental change to this data as historical data should not be changed.
    • Most organizations have legislative restrictions or governance restrictions to keep data for a period of time.  Once this data is past a certain age it should be permanently archived.  This is easy to do by moving data to an archive table, and archiving the data permanently.  To archive permanently the filegroup can be taken offline and backed up.  In the event the data needs to be viewed again, the filegroup could be reattached.
    • In a disaster recovery situation where high availability (i.e. clustering, mirroring and log shipping fails), one only needs to restore the core file group, primary filegroup and log to allow business to trade.  This  is only available in the enterprise solution of SQL server.
    • Backup windows can be drastically reduced as history only needs to be backed up after data is moved into it.  This typically takes the major volume of your database.  Backups only need to be the primary filegroup, log files and History file groups.

    I/O Parallelism

    Should data tables be large, it is recommended that you split you create multiple files within a filegroup.  The recommendation is one file per CPU that is  assigned to I/O.  The placement of files should be on separate drives / arrays or SAN lungs as to provide disk drive concurrent reads. 

    image

    The benefits

    • Parallel I/O processing will drastically improve performance, especially on OLAP type databases.

    Schema and User Data partitioning

    It is strongly recommended to keep your user tables, indexes in other filegroups and not in the primary filegroup.

    image

    image

    The benefits

    • Primary file group typically very small and backup very quickly.  Typical size is from 2Mb - 30Mb (that is a huge amount of standard accounts, stored procedures and views).
    • Unless security or schema's are change frequently, there is no need to backup the filegroup daily.  However due to the size one may wish to back it up daily.
    • Non clustered indexes can be kept separate to data as indexes can be rebuilt.
    • In a disaster recovery situation, the enterprise edition of SQL server allows one to bring a database online with only the primary file.  The DBA's can then electively choose to bring on core data allowing business to trade.  Historical data can be brought online at a later stage. 

    Disaster Recovery

    A Disaster Recovery situation is where all other options have failed, that is your clustering, mirroring and log shipping has failed.  As DBA's this step must be planned for as complete shutdown of servers can close businesses.  At times we place expensive hardware and software solutions with full redundancy only to find that the impossible actually happens.  I am sure with time, people will post horror stories like "DR will never fail"  ... uhm yeah, right!

    When one is faced with a disaster situation, business continuity must continue and that means business must still make money.  One needs to look at what is important and not important to business.  Take a look at the following example, note that every business may have different requirements and this is in the event of a complete disaster.

    Important Not important
    Trade and make money Performance
    Restricted access History
      Access to archived data
      Decision support systems
      General reporting
      Trend analysis

    In a disaster situation

    • Restore the primary filegroup for schema and security
    • Restore core data allowing business to trade
    • Over time restore the history and archive data
    • Rebuild indexes

    Backup windows

    Many companies are with large are multiple database may not have enough time in off-peak hours to back the databases up fully.  With a few changes differential and log backups can be introduced.  This too may exceed time available.  Another problem is backup capacity.  A large volume of databases have active data and historical data for governance reasons, when digging into this you may notice that 80%+ of your data is historical, thus backing the same stuff up daily where a weekly or monthly backup would suffice.

    Secondly, all the non clustered indexes may also take up a significant portion of the database size and depending on the type and characteristics of the database it may be around 40% of your size.  Should these indexes not be backed up, it will not cripple business as no data is lost and they can easily be recreated (a good reason to keep scripts).

    By placing active or core data in one filegroup and historical data in another filegroup will allow you to place different backup schedules on each filegroup. This could reduce backup size and allow backups to complete within the backup window.

    On larger databases a full backup may take several hours to make, and even longer to restore as empty pages need to be created.  Let us presume your restore takes 8 hours and upon arriving at work you notice the database is destroyed and a restore made, Eight  hours later users can start working ... oops close of business. 

    In many cases core data which is sufficient to trade is about 5-15% of database size, again your situation may differ depending on the database purpose. 15% of eight hours is 72 minutes, thus in under two hours business. 

    Would you rather be up in two hours albeit slow and limited functionality or in eight hours with full functionality?

    The not so nice

    With the exception of parellelism, it is very hard to implement these features after the database has been designed. 

    • Partitioning of data into active and historical will require developers to design tables accordingly. 
    • Table partitioning using SQL 2005 can be used, however poorly designed databases will not lend itself to this.
    • Complex hierarchical database will battle to make use of many of these features.
    • Disaster limited functionality will require front-end applications to be aware that this could happen and a query to a table does not work as the table is offline.
    • Scripts need to be maintained to rebuild indexes.
    • Developers should create tables in the relevant filegroups as DBA's my not fully understand all the implications of the business logic.
    • Not all databases will benefit from this.
    • Every database has it's own characteristics and each one needs to be addressed, one shoe definitely does not fit all.

    Scenarios

    Below are a few scenarios to better understand filegroups.

    Scenario 1

    A database of 1.8 terabytes needs to be created, there are 2 X 1 TB raid configured arrays and 1 X 500 GB mirrored set. Thus, a large database needs to be placed onto a hard drive, however no single drive or SAN lung is able to accommodate the file.  To solve this problem, it is still recommended that the log file and database files are kept on separate drives as this may assist in disaster recovery.  A filegroup for the database is created which contains two files, one on each drive.  Below is the illustration.

    image

    Scenario 2

    A client has a small database below 100Gb which needs to be created.  The backup time with existing hardware for this database is about 1 hour and well within acceptable backup window times.

    image

    Scenario 3

    A client is about to embark on a new development project where the database schema still needs to be defined and different inputs to the design are being investigated.  The database is expected to grow to 750 Gb within the next 3 years.  The majority of data will be history and users will be querying this history.

    The primary file group

    • Only contains system tables with schema, users and security rights.
    • Will be small and typically between 10Mb - 40Mb
    • Full backups can be done daily as to get security changes.

    Core data

    • This date changes daily to reflect current active business transactions for the month.
    • Daily backups done on this filegroup.

    History

    • This filegroup will be read only and only changed on month end procedures to move from transaction from core to history.
    • As this data is semi static, it only needs to be backed up weekly and directly after a month end procedure.  This should reduce time to back up significantly.

    Indexes

    • Non clustered indexes will be stored in the index file group
    • Backed up daily if sufficient time window
    • In a Disaster Recovery situation, these can be rebuilt via script

    Audit (Optional)

    • Audit and log data is retained in this filegroup, however one may decided to place in core.
    • Backed up daily.

    image

    Scenario 4

    A large database exists where transactions for several years are kept.  The business has a need to access data for the past 2 years due to warranty claims.  Older data needs to be kept for governance reasons.  The warranty table has 128 000 000 rows and insert times for new products are unacceptably long.  To remedy this the existing table can be partitioned into four file groups and indexes created on these file groups as well.

    image

    Scenario 5

    The company has a large OLAP database for management reporting and decision support.  The database is predominantly a read \ only database.  Information is updated in the evenings using Sql Server Integration Services.  Performance of this database is important. 

    The design will split the database over several physical drives or SAN lungs according to the number of processors the server has (in this case 4).  Due to the large size of the data, the indexes will be placed in a separate filegroup and not backed up.  These could be recreated in the event of a Disaster Recovery situation.  The indexes should also be placed over several drives for parallelism.

    image

    Posted Jun 28 2007, 07:28 AM by Brett with 1 comment(s)
    Filed under:
  • Designing databases - OLTP and OLAP

    Abstract

    Before even attempting to design a database, one should understand data characteristics and behaviors of database models.  The design of the database can be radically different based on what the data is going to be used for.  This blog will attempt to discuss the different data models with regards to business databases.

    Categorizing databases

    Databases can be described as either On-line transactional processing and On-line analytical processing stores.

    image

    On-Line Transaction Processing

    Day-to-day business activities, events and transactions are recorded and captured in client systems. These systems a the systems that allow clients and users to trade, make money and deliver service and\or product.  It presents a snapshot of detailed information of what occurred on a given business day.  These systems normally contain historical data going back for several years to meet company governance and legislative requirements.

    The OLTP give a view of transactions in the business that are happening today and now.

    What should the OLTP system be handling

    • Manual transaction capturing
    • Batch transaction processing of current data
    • Transactional information
    • Current business activities
    • Current workflow including stage and state
    • Search and find functionality of recent business transactional activity
    • Document creation for the purpose of carrying out a transaction, e.g. Invoices, Delivery notes, Job cards.
    • Historical detailed transactions
    • Time sensitive information

    What should the OLTP system not be handling

    • Reporting
    • Management information
    • Decision support systems
    • Aggregated and summarized information

    On-Line Analytical Processing

    An OLAP solution is database that presents summarized and aggregated information that management and information workers will use to assist in decision support.  This typically should w

    What should the OLAP system be handling

    • Reports over time
    • Summarized data 
    • Aggregated data
    • Data used for trend analysis
    • Non time sensitive information

    What should the OLAP system not be handling

    • Transactional forms and reports used in day-to-day business
    • Detailed transactions, unless there is a specific drill down reporting need.

    The importance of splitting the databases

    One does not need a degree in quantum physics to grasp this one as it is rather simple and common sense. 

    The OLTP benefits

    Small current footprint of data - The OLTP database should be optimized with a small foot print of information that allows the business to continue trading today.  This will allow DBA's to manage backups more efficiently where only current data is backed up.  Historical transactions could be scheduled over quite times.

    Normalized.  The database focuses on highly normalized tables with strong database referential  backing.  This will assist in the drive to ensure the current data is accurate and not compromised.

    Performance tuned.  The tables will have a minimal set of indexes on it as to support fast transactional processing

    Historical transaction splitting.  In very large databases, historical data is normally partitioned into separate tables, thus allowing for smaller current tables with current and active data.  In the event that historical transactions need to be queried, it can be as the front-end will access the history table.

    Data locks. As the active data set will be smaller, lock durations may be decreased.

    Lock contention.  As the OLTP solution will in a separate database than the OLAP data, long running reports will not affect current transactional processing tasks by holding read locks for long periods of time.

    Deadlock reduction.  Although deadlocks are created by inconsistent data access, many OLTP vs OLAP deadlocks could be avoided.  Deadlocks are caused by Insert, Update and Delete actions conflicting with other Insert, Update, Delete and Select statements.

    The OLAP benefits

    BI Technology. Technologies such as SQL Analysis services are far better tuned to dealing with summarization, slice 'n dicing and decision support solutions than a stock standard relational database.

    Demoralized data.  Data in the OLAP database can be demoralized to include submersed data. This should drastically cut down computational time for many reports.  The amount of joins are reduced thus reducing lookups, hashes and merging.

    Index optimization.  Many indexes can be placed on the data which are geared for report processing performance.  As data is not being added all the time, there will be no conflict with OLTP systems.

    Lock reduction. The database is brought to an absolute minimum on the database as it is SELECT only store, the tables gladly run with multiple read locks.

    Client facing system

    Although the client may need access to both OLAP and OLTP solutions, it is easy to buffer from a code perspective.  The user is practically oblivious to the access to two different databases.  A simplified model is represented below.

    image

    Synchronizing the data

    The updating of the OLAP environment is done by an Extract Translate and Load process.  This ETL process is typically developed using SQL Server Integration Services (SSIS) packages.  These ETL process is then scheduled to run in the evening or during quite load times.  For reports that need to be updated frequently, these jobs could run every couple of hours.  In most cases the transaction volumes for updating will be relatively low.

    image

     

    Future blogs will delve deeper into these core concepts where other benefits will be realized.

    Posted Jun 26 2007, 10:35 PM by Brett with no comments
    Filed under:
  • Database programmer vs Database Administrator

    Abstract

    This blog is the start of a series of blogs to assist programmers in creating a robust database. Not only will this benefit the business user or client, it should assist the boys and girls that attend to the database infrastructure and administration.  A solid data design is an art and not simply a "CREATE DATABASE" with a few "CREATE TABLE" statements. 

    The gap between database design and administration need to be narrowed and database designers need to take a look at the design as simple oversights actually ruin the system in the eyes of the business user.

    The cowboy dig

    Through my consulting and training of developers, database administrators, business intelligence administrators and information workers using Microsoft SQL server I have noticed some rather disturbing patterns between these different parties.  These differences may come from ignorance to the technology and other parties actual needs.

    In this blog, I will attempt to right some wrongs with regards to developing databases for the SQL environment and in so doing it will assist information workers and administrators with their day to day job.  The ultimate winner is the satisfaction of a sound database design that the client obliviously is unaware of, but in which the technical team actually appreciate. 

    I have seen some rather ridiculous database designs and ego's enforcing stupid ideas on a database, some highlights are

    • A 1.5 TB database where dear DBA refused to put indexes on the database as it "slowed" down the performance of the server.
    • A development team that had no database referential integrity in the database as their "data tier" had all the integrity logic.
    • The single enterprise "mother" of a database that encompassed all business units needs, however any small change had a radical cross business impact.
    • The development team that created a enterprise application with only five tables, in which two tables contained the data and the other three managed the meta data.  These guys really thought they could write a better meta data manager on top of SQL server.   This one I am proud to say, I walked away wishing them the best of luck.
    • One of my favorites is the client who's dev team actually normalized the data to the extent of firstnameId, lastnameId, address number, building name, street name, street type and so on.  No this was not some form of GIS application but a run of the mill product sales system.

    Those were the funny ones, however the serious issues that I notice commonly arise are

    • With increased concurrence, locking issues radically impact design.
    • Weak index creation and the reliance the administrative team have on the development teams index creation.
    • Bad use of file groups that limit the manageability of the database when it comes to backup and restore times.
    • Design issues that impact on the high availability of a database
    • No distinction between Online Transaction Processing (OLTP) and Online Analytical Processing (OLAP).
    • Data history management.
    • Lack of knowledge of legislative requirements with regard to data retention and audit controls.
    • General lack of thorough data integrity in databases.
    • Use of private and confidential information in test and development environments that totally contravene information privacy acts. 
    • The lack of testing of the database.

    The message

    There are too many cowboys out there developing systems and the corresponding database leaving a bad taste in many users mouths.  This gung-ho cowboy style of development with the aim to get the system out the door needs to come to an end.  My message to these cowboys is rather simple,  software development and database design is not for you, think of changing career to something that involves a cattle ranch where you can be a real cowboy.

    Now for the serious folk, lets get down to business and develop some kick ass databases that we can be proud of.

    Series content

    My fingers are now rearing to go and the keyboard is lukewarm, as I add more to the series I will edit the links below for easy reference

    Topics

    Um, give me a chance to write some, this most definitely will not happen over night, but please keep visiting for updates. 

    Please drop your suggestions in the Forums, share your horror stories.

    Ideas and To Do's

    • Designing with OLTP and OLAP in mind
    • Designing databases with High Availability in mind
    • Database file structures to minimize backup and restore times
    • Designing a database structure with changing schemas
    • Demystifying what is a Data Tier
    • Managing large databases
    • Indexes, statistics and the query optimizer
    • Using replication in the right places
    • Securing a database (Oh boy I can see yet a full series just in this one)
    • Data integration
    • Establishing a sound data integrity model
    • Alignment with Data and Information Architectures.
    • Testing the design
    • Rapid database prototyping
    • Designing an audit mechanism into the database
    • Designing an active, historical and achievable database
    • Some highlights governance facts including the companies act and the information act
    Posted Jun 26 2007, 02:04 PM by Brett with no comments
    Filed under:
  • Façade Pattern

    The façade pattern is a structural pattern and only available in object orientated languages. The façade patterns creates a simplified interface to a larger body of systems and routines.

    What is it supposed to solve

    In everyday object orientation we encapsulate complex logic within a single method call, this single method however calls many other routines in other systems to form a complex chain of events, this is typically a façade. However, unlike encapsulation where logic of a single class is hidden, Facades may instantiate calls to many other systems.

    Common uses

    • Wrap low level API calls into a more useable component
    • Combines several framework components into easy to use components
    • Buffers client application from complex inner workings
    • Expose an API, thus hiding inner workings of a component
    • Decouples client from backend systems, client only needs to communicate with façade.
    • Client only has one dependency.

    UML Diagram

    Facade

    Façade

    The façade exposes a method that contains logic to call multiple methods in other subsystems. Typically each subsystem has manages it's own business domain.

    Sub Systems

    Each sub that provides independent functionally.

    Client

    The client application makes use of the façade and is oblivious to what the façade actually does.

    Implementation notes

    Sample C# code

    namespace Brett.Patterns.GangOfFour.FacadePattern.Structural
    {
        using System;
    
        /// 
        /// The demonstration application
        /// 
        public class FacadePatternDemo
        {
            /// 
            /// The entry point to the demonstration application
            /// 
            static void Main()
            {
                //Create the facade
                Facade facade = new Facade();
                //Execute Facade Method one hiding it's complexity
                facade.FacadeMethod1();
                //Execute Facade Method two hiding it's complexity
                facade.FacadeMethod2();
            }
        }
    
        /// 
        /// Some complex system.
        /// 
        /// 
        /// Typically this sytem will not be in the same assembly
        /// 
        internal class SubSystemOne
        {
            public void SomeMethodInSubSystemOne()
            {
                Console.WriteLine( "\tExecuting - SomeMethodInSubSystemOne()");
            }
        }
    
        /// 
        /// Another complex system.
        /// 
        /// 
        /// Typically this sytem will not be in the same assembly
        /// 
        internal class SubSystemTwo
        {
            public void SomeMethodInSubSystemTwo()
            {
                Console.WriteLine("\tExecuting - SomeMethodInSubSystemTwo()");
            }
        }
    
        /// 
        /// Yet another complex system.
        /// 
        /// 
        /// Typically this sytem will not be in the same assembly
        /// 
        internal class SubSystemThree
        {
            public void SomeMethodInSubSystemThree()
            {
                Console.WriteLine("\tExecuting - SomeMethodInSubSystemThree()");
            }
        }
    
        /// 
        /// The final complex system.
        /// 
        /// 
        /// Typically this sytem will not be in the same assembly
        /// 
        internal class SubSystemFour
        {
            public void SomeMethodInSubSystemFour()
            {
                Console.WriteLine("\tExecuting - SomeMethodInSubSystemFour()");
            }
        }
    
        /// 
        /// The exposed facade that hides the complexity of calling all other
        /// systems tasks
        /// 
        public class Facade
        {
            SubSystemOne _one;
            SubSystemTwo _two;
            SubSystemThree _three;
            SubSystemFour _four;
    
            /// 
            /// The constructor initializing the other systems
            /// 
            public Facade()
            {
                _one = new SubSystemOne();
                _two = new SubSystemTwo();
                _three = new SubSystemThree();
                _four = new SubSystemFour();
            }
    
            /// 
            /// Demonstrates a facade method that only calls two sub systems.
            /// 
            public void FacadeMethod1()
            {
                Console.WriteLine( "\r\nFacadeMethod1() ");
                _one.SomeMethodInSubSystemOne();
                _four.SomeMethodInSubSystemFour();
            }
    
            /// 
            /// Another facade method that hides the calling of other systems.
            /// 
            /// 
            /// There could be many facade methods.
            /// 
            public void FacadeMethod2()
            {
                Console.WriteLine("\r\nFacadeMethod2() ");
                _four.SomeMethodInSubSystemFour();
                _three.SomeMethodInSubSystemThree();
                _two.SomeMethodInSubSystemTwo();
                _one.SomeMethodInSubSystemOne();
            }
        }
    
    }
    
  • Singleton Pattern

    Definition

    The singleton pattern is used to restrict the creation of a class to only one object.

    What it is supposed to solve

    By only restricting the creation to a single object, it allows thus one to control the creation of the object and only use one copy of the object. It is typically used to store:

    • Configuration information
    • Current user context for windows and smart clients
    • Represent shared resources
    • Cache controllers and caches
    • System managers where only one type of module can be created.
    • Façade objects
    • State objects

    The difference between a singleton and a public static variable is that one can control the accessor to the object. The creation of the singleton can be on demand and only when first used, thus a lazy creation. Finally one can control the creation of the singleton.

    Singleton should not be used for global variables, although they can be. One should rather create static variables for global variables. However, should you wish to control the persistence or purpose of the "global variable", one would rather choose a singleton.

    A singleton is also useful for passing the object as a reference type and not a value type which static variables could be (obviously depending on the type).

    UML Diagram

    image

    The classes / object in this pattern are

    Singleton

    The singleton class defines the singleton, however it also controls the creation process of a singleton.

    Implementation notes

    Singletons are easy to implement, one creates a static variable to store the instance of the class. Secondly one creates a private constructor, thus preventing any other class creating the instance. Lastly a public static property or method is created to return the static variable.

    Sample C# code

    The code below demonstrates how to conceptually create a singleton class and use it. The code also proves that the singleton is only one instance of the object.

    namespace Brett.Patterns.GangOfFour.Singleton.Structural
    {
        using System;
        using System.Collections.Generic;
        using System.Text;
    
        class SingletonDemo
        {
            class Singleton
            {
                private static Singleton _instance;
    
                private Singleton()
                {
                    //Perform any initialization
                }
    
                /// 
                /// This returns the instance of the method
                /// 
                /// 
                /// Many singleton examples create a method that returns the singleton,
                /// I have chosen to use a property.
                /// 
                public static Singleton Instance
                {
                    get
                    {
                        // Create the instance of if it does not exist.
                        // This is a lazy create
                        if (_instance == null)
                        {
                            // Create an instance of the singleton
                            // Note that we are able to call the private constructor as
                            // the code is in the same class
                            _instance = new Singleton();
                            //Other instanciation code can go here
                        }
                        // Return the variable
                        return _instance;
                    }
                }
    
            }
    
            /// 
            /// The test application with a the entrypoint Main.
            /// 
            static void Main()
            {
                //The commented line below will not compile as the
                //constructor is private
                //Singleton singleton = new Singleton();
    
                //Get the singleton instance
                //Note that the first usage of the Singleton.Instance property
                //will create the singleton
                Singleton singleton1 = Singleton.Instance;
                Singleton singleton2 = Singleton.Instance;
    
                //Prove that they are the same
                if (singleton1 == singleton2)
                {
                    Console.WriteLine( "Both objects are the same" );
                }
            }
        }
    }
    
    
  • Factory Method Pattern

    Definition

    The Factory Method Patten defines a mechanism for creating an object. The factory however decides what subclasses to use which in turn decide which class to instantiate. The Factory Method lets a class defer instantiation to subclasses.

    What it is supposed to solve

    In object orientation programming we create classes to define entities; we then create instance objects of these classes. Typically we allow other developers to create the object, however in creation of the object there is very little control over the creation. We can thus create a factory that creates instances of the class, in creation, the factory can do multiple things, such as

    • Check security whether the user is allowed to create objects
    • Audit the creation of the object
    • Use business rules to determine what type of object to create
    • Control the creation process
    • Initialize certain variables, such as identifiers, counters or numbers.

    The factory thus lends itself to controlled creation of the object.

    Some developers may be prone to putting logic into the constructor of the class, however this is flawed as resource would have already been created for the object and rising errors in the constructor incurs unnecessary resource creation. A factory and a creation method will thus, first check the business logic and rules for creation and only if valid would it create the object. Thus the object will only be created post verification.

    UML Diagram

    image

    The classes / objects in this model are:

    Product 

    This class defines the object that needs to be created by the factory method. 

    ConcreateCreator 

    The ConcreateCreator class has a FactoryMethod that is responsible for creating the instance of the product.

    The FactoryMethod does need to validate and initialize the 

    Creator 

    The creator is an abstract class that defines the signature of a factory method. 

    Sample C# code

    The code below demonstrates how to conceptually use the Factory Method pattern. Although abstract classes have been used, you may wish to implement these as interfaces.

    namespace Brett.Patterns.GangOfFour.FactoryMethod.Structural
    {
        using System;
    
        /// <SUMMARY>
        /// The demonstraiton application with the Main entrypoint.
        /// </SUMMARY>
        public class StructureDemoApp
        {
            static void Main2()
            {
                Creator creator = new ConcreteCreator();
                Product product = creator.FactoryMethod();
    
    
            }
        }
    
        /// <SUMMARY>
        /// 
        /// </SUMMARY>
        /// <REMARKS>
        /// Notice that the ctor is internal, meaning that the ConcreteCreator
        /// that is in the same assembly will be able to create it.  However any
        /// other system outside of this assembly will not be able to create
        /// a product by new Product() and thus is forced to use the FactoryMethod()
        /// </REMARKS>
        public class Product
        {
            internal Product()
            {
            }
        }
        /// <SUMMARY>
        /// This abstract class provides a signature footprint for concreate
        /// creators.  The Creator also only works on the base product and not 
        /// future child/sub classes.
        /// </SUMMARY>
        public abstract class Creator
        {
            public abstract Product FactoryMethod();
    
        }
        /// <SUMMARY>
        /// This ConcreateCreator class is responsible for creating and 
        /// initializing new products.  As this class is in the same assembly
        /// as the product, it is able to instanciate the class.
        /// </SUMMARY>
        /// <REMARKS>
        /// This is a simple implementation of a factory method and your designs
        /// should include more logic to determine whether the object can be created
        /// or not.
        /// </REMARKS>
        public class ConcreteCreator : Creator
        {
            public override Product FactoryMethod()
            {
                Console.WriteLine( "ConcreteCreator creating a new Product" );
                return new Product();
            }
        }
    }
    

    Real World Sample C# Code

    The demonstration code creates a solution that allows customers to open bank accounts. The type of bank account opened depends on the persons monthly income and the factory will either open a Blue or Gold account.

    namespace Brett.Patterns.GangOfFour.FactoryMethod.Structural
    {
        using System;
        using System.Collections.Generic;
    
        /// <summary>
        /// This is the  demonstration application with the Main entrypoint.
        /// </summary>
        public class RealWorldDemoApp
        {
            static void Main()
            {
                //Create a collection to hold a list of customers
                List<Person> customers = new List<Person>();
                //Create the first customer
                Person customerA = new Person();
                customerA.Name = "A.N. Other";
                customerA.MonthlySalary = 8000.00M;
                //Create the second customer
                Person customerB = new Person();
                customerB.Name = "J. Doe";
                customerB.MonthlySalary = 3000.00M;
                //Add the two customers to the customers collection
                customers.Add(customerA);
                customers.Add(customerB);
                //Create a loan factory
                BankAccountFactory loans = new BankAccountFactory();
                //Open a loan account for the two customers
                loans.OpenNewAccount(customerA);
                loans.OpenNewAccount(customerB);
                //Generate a report of customers and their accounts
                foreach (Person p in customers)
                {
                    Console.WriteLine( "Customer: {0}", p.Name );
                    Console.WriteLine( "\tMonthly Salary: {0}", p.MonthlySalary);
                    Console.WriteLine("\tAccount#\tType\tLimit");
                    foreach (BankAccount a in p.Accounts)
                    {
                        Console.WriteLine("\t{0}\t\t{1}\t{2}", a.AccountNumber, a.AccountType, a.CreditLimit );
                    }
                }
    
            }
        }
    
        /// <summary>
        /// This class defines our customers with name, monthly salary and a collection of accounts.
        /// </summary>
        public class Person
        {
            private string _name; 
            private decimal _monthlySalary;
            private List<BankAccount> _accounts;
    
            // The name property
            public string Name
            {
                get { return _name; }
                set { _name = value; }
            }	
            //The monthly salary property
            public decimal MonthlySalary
            {
                get { return _monthlySalary; }
                set { _monthlySalary = value; }
            }
            //The accounts
            public List<BankAccount> Accounts
            {
                get {
                    //This is a lazy create of the accounts list
                    if (_accounts == null)
                    {
                        _accounts = new List<BankAccount>();
                    }
                    return _accounts;
                }
            }
    	
        }
    
        /// <summary>
        /// Enumeration to store the different types of accounts, each type
        /// of account will need you to develop an account class for it.
        /// </summary>
        public enum AccountTypeEnum { Blue, Gold }
    
        /// <summary>
        /// A generic type of account factory that can open an account,
        /// in future releases we could implement different types of accounts
        /// that the client is able to create, e.g. bank, loan, home loan, savings
        /// etc.  However no matter what type of account we have, a custoemr
        /// should be able to open the account
        /// </summary>
        public abstract class AccountFactory
        {
            public abstract BankAccount OpenNewAccount(Person person);
        }
    
        /// <summary>
        /// A concrete factory for a bank account class
        /// </summary>
        public class BankAccountFactory : AccountFactory
        {
    
            /// <summary>
            /// This method determines what type of bank account to open
            /// based on the persons monthly salary.
            /// </summary>
            /// <param name="person"></param>
            /// <returns></returns>
            public override BankAccount OpenNewAccount(Person person)
            {
                //Cannot pass a null person
                if (person == null)
                {
                    throw new NullReferenceException("person cannot be null");
                }            
                // Create the new account
                BankAccount newAccount;
    
                if (person.MonthlySalary <= 5000)
                {
                    newAccount = new GoldBankAccount();
                }
                else
                {
                    newAccount = new BlueBankAccount();
                }
                //Add it to the accounts collection
                person.Accounts.Add(newAccount);
                //Return the account
                return newAccount;
            }
        }
    
        /// <summary>
        /// This class represents a comm
        /// </summary>
        public abstract class BankAccount
        {
            private readonly string _accountNumber;
            private Decimal _creditLimit;
    
            /// <summary>
            /// Contructor for a bank account
            /// </summary>
            public BankAccount()
            {
                _accountNumber = NumberGenerator.GetNextAccountNumber();
            }
    
            /// <summary>
            /// Abstract method to return the account type
            /// </summary>
            public abstract AccountTypeEnum AccountType
            { get; }
    
            /// <summary>
            /// Return the credit limit of the account
            /// </summary>
            /// <remarks>
            /// The credit limit can only be set from internally and not 
            /// outside this assembly.
            /// </remarks>
            public Decimal CreditLimit
            {
                get { return _creditLimit; }
                internal set { _creditLimit = value; }
            }
    	
            /// <summary>
            /// Retruns the account number.  Read only.
            /// </summary>
            public string AccountNumber
            { get { return _accountNumber; } }
    	
        }
    
    
        /// <summary>
        /// This defines Gold Bank accounts
        /// </summary>
        public class GoldBankAccount : BankAccount
        {
            public GoldBankAccount()
            {
                this.CreditLimit = 10000.00M;
            }
            public override AccountTypeEnum AccountType
            {
                get { return AccountTypeEnum.Gold; }
            }
        }
    
        /// <summary>
        /// Defines a blue banking account.
        /// </summary>
        public class BlueBankAccount : BankAccount
        {
            public BlueBankAccount()
            {
                this.CreditLimit = 0.00M;
            }
            public override AccountTypeEnum AccountType
            {
                get { return AccountTypeEnum.Blue; }
            }
    
        }
    
        /// <summary>
        /// This little class is a rough number generator class
        /// however it will start bank account numbers
        /// </summary>
        internal static class NumberGenerator
        {
            private static int _accountCounter;
    
            // Intitalizes the first account number to 100
            static NumberGenerator()
            {
                _accountCounter = 100;
            }
    
            //Increments the account number and returns 
            // a formatted string with five digits.
            public static string GetNextAccountNumber()
            {
                _accountCounter++;
                return _accountCounter.ToString("00000");
            }
        }
    
    }
    

    See Also

    • Abstract Factory Pattern – use this if you want to create a factory method that first creates concrete factories, which in turn will create the products.
  • Introducing design patterns

    When designing solutions, design patterns propose a solution to common software design problems. The pattern provides a template for you to choose and suggests a typical class structure and relationships between classes. These patterns are normally abstract as it suggests structure of the solution, it does not however solve your applications design. In using a pattern, you will follow a standard class structure for your solution.

    These design patters are thus a guideline for you to use in structuring your application. In object orientated programming, we need to create and destroy objects, communicate between objects and maintain relationships. Patterns give you some ideas for the creation, communication and relationships of classes and objects.

    In your application, you may choose to implement a pattern for a few of your classes, and thus be able to understand its use. Design patterns typically are proven techniques to solve a software design pattern and instead of inventing creative ways to design your system, use a pattern. In actual fact, many of the solutions you have developed may directly or indirectly use design patterns.

    Learning patterns

    When starting out patterns learn the purpose of the pattern and how to create such a pattern. Once you have mastered each pattern, you will typically be required to design a solution with combinations of one or more pattern. A typically real world application may use several patterns together to achieve a result.

    History (from www.wikipedia.com)

    Patterns originated as an architectural concept by Christopher Alexander (1977/79). In 1987, Kent Beck and Ward Cunningham began experimenting with the idea of applying patterns to programming and presented their results at the OOPSLA conference that year. In the following years, Beck, Cunningham and others followed up on this work.

    Design patterns gained popularity in computer science after the book Design Patterns: Elements of Reusable Object-Oriented Software was published in 1994 (Gamma et al). That same year, the first Pattern Languages of Programs conference was held and the following year, the Portland Pattern Repository was set up for documentation of design patterns. The scope of the term remained a matter of dispute into the next decade.

    Although the practical application of design patterns is a phenomenon, formalization of the concept of a design pattern languished for several years.

    Classification

    Design patterns are classified into common underlying problems in software design. Below lists the pattern areas

    Creational patterns

    In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.

    Creational Patterns

    Abstract factory pattern

    centralize decision of what factory to instantiate

    Factory method pattern

    centralize creation of an object of a specific type choosing one of several implementations

    Builder pattern

    separate the construction of a complex object from its representation so that the same construction process can create different representations

    Lazy initialization pattern

    tactic of delaying the creation of an object, the calculation of a value, or some other expensive process until the first time it is needed

    Object pool pattern

    avoid expensive acquisition and release of resources by recycling objects that are no longer in use

    Prototype pattern

    used when the inherent cost of creating a new object in the standard way (e.g., using the 'new' keyword) is prohibitively expensive for a given application

    Singleton pattern

    restrict instantiation of a class to one object

    Structural Patterns

    These patterns define and enforce relationships between entities defined.

    Structural Patterns

    Adapter pattern

    'adapts' one interface for a class into one that a client expects

    Aggregate pattern

    a version of the Composite pattern with methods for aggregation of children

    Bridge pattern

    decouple an abstraction from its implementation so that the two can vary independently

    Composite pattern

    a tree structure of objects where every object has the same interface

    Container pattern: create objects for the sole purpose of holding other objects and managing them

    Decorator pattern

    add additional functionality to a class at runtime where subclassing would result in an exponential rise of new classes

    Extensibility pattern

    aka. Framework - hide complex code behind a simple interface

    Façade pattern

    create a simplified interface of an existing interface to ease usage for common tasks

    Flyweight pattern

    a high quantity of objects share a common properties object to save space

    Proxy pattern

    a class functioning as an interface to another thing

    Pipes and filters

    a chain of processes where the output of each process is the input of the next

    Private class data pattern

    restrict accessor/mutator access

    Behavioral Patterns

    These patterns identify communication between entities.

    Structural Patterns

    Chain of responsibility pattern

    Command objects are handled or passed on to other objects by logic-containing processing objects

    Command pattern

    Command objects encapsulate an action and its parameters

    Interpreter pattern

    Implement a specialized computer language to rapidly solve a specific set of problems

    Iterator pattern

    Iterators are used to access the elements of an aggregate object sequentially without exposing its underlying representation

    Mediator pattern

    Provides a unified interface to a set of interfaces in a subsystem

    Memento pattern

    Provides the ability to restore an object to its previous state (rollback)

    Observer pattern

    aka Publish/Subscribe or Event Listener. Objects register to observe an event which may be raised by another object

    State pattern

    A clean way for an object to partially change its type at runtime

    Strategy pattern

    Algorithms can be selected on the fly

    Template method pattern

    Describes the program skeleton of a program

    Visitor pattern

    A way to separate an algorithm from an object

    Single-serving visitor pattern

    Optimise the implementation of a visitor that is allocated, used only once, and then deleted

    Hierarchical visitor pattern

    Provide a way to visit every node in a hierarchical data structure such as a tree.

    The above list is not conclusive and will be added to in the future.

    Arguments against patterns

    Some designers claim that patterns are not reusable and as a designer you have to develop code for your application that specifically implements a pattern. Every application type has different characteristics, behaviors and rules which dictate the need of different pattern combinations. For example we may have a creational pattern that creates an instance of an object, say customer. In different organizations and different types of systems, the creation of a customer will follow different rules, thus requiring different patterns.

    Some authors indicate that design patterns are mere forms of abstraction and that "patterns" are in fact borrowed from object orientation Often the Model-View-Controller pattern is touted about as an example of a pattern and a set of classes created, however if one looks at different implementations of MVC, one would quickly see different that the designs are also different. However, a common idea is used in all three solutions, that is of a model, a view and a controller.

  • Course 2787 - Designing Security for Microsoft SQL Server 2005

    Course 2787: Two days; Instructor-Led

    Introduction

    This two-day instructor-led course enables database administrators who work with enterprise environments to design security for database systems using Microsoft SQL Server 2005. The course emphasizes that students should think about the whole environment, which includes business needs, regulatory requirements, network systems, and database considerations during design. Students will also learn how to monitor security and respond to threats.

    Audience

    This course is intended for current professional database administrators who have three or more years of on-the-job experience administering SQL Server database solutions in an enterprise environment.

    Prerequisites

    Before attending this course, students must:

    • Have basic knowledge of security protocols and how they work. For example, Windows NT LAN Manager (NTLM) or Kerberos.
    • Have basic knowledge of public key infrastructure (PKI) systems. For example, how public and private keys work, strengths and weaknesses, and what they are used for.
    • Have working knowledge of network architectures and technologies. For example, how a firewall works, how IPSec works in a networking context, and common vulnerability points.
    • Have working knowledge of Active Directory directory service. For example, security models, policies, group policy objects (GPOs), and organizational units (OUs).
    • Be able to design a database to third normal form (3NF) and know the tradeoffs when backing out of the fully normalized design (denormalization) and designing for performance and business requirements in addition to being familiar with design models, such as Star and Snowflake schemas.
    • Have strong monitoring and troubleshooting skills.
    • Have experience creating Microsoft Office Visio drawings or have equivalent knowledge.
    • Have strong knowledge of the operating system and platform. That is, how the operating system integrates with the database, what the platform or operating system can do, interaction between the operating system and the database.
    • Have basic knowledge of application architecture. That is, different methods of implementing security in an application, how applications can be designed in three layers, what applications can do, the interaction between applications and the database, and interactions between the database and the platform or operating system.
    • Have knowledge about network security tools. For example, sniffer and port scanning. Must understand how they should be used.
    • Be able to use patch management systems.
    • Have knowledge of common attack methods. For example, buffer overflow, and replay attacks.
    • Be familiar with SQL Server 2005 features, tools, and technologies.
    • Have a Microsoft Certified Technology Specialist: Microsoft SQL Server 2005 credential or equivalent experience.

     In addition, it is recommended, but not required, that students have completed:

    • Course 2778: Writing Queries Using Microsoft SQL Server 2005 Transact-SQL.
    • Course 2779: Implementing a Microsoft SQL Server 2005 Database.
    • Course 2780: Maintaining a Microsoft SQL Server 2005 Database.

     Course Outline

    Module 1: Introduction to Designing SQL Server Security

    This module introduces the principles and methodology of designing SQL Server security. This module also explains the benefits of having a security policy in place and the process of creating a security policy. In addition, this module teaches you the importance of monitoring the security of SQL Server.

    Lessons

    • Principles of Database Security
    • Methodology for Designing a SQL Server Security Policy
    • Monitoring SQL Server Security
    Module 2: Designing a SQL Server Systems Infrastructure Security Policy

    This module provides the guidelines for implementing server-level security using authentication methods. This module also provides the knowledge required to develop a Microsoft Windows server-level security policy. To enable you to do this, this module provides the guidelines to create password policy and determine service accounts permissions. In addition, this module explains how to select an appropriate encryption method to develop a secure communication policy. This module also explains the monitoring standards for SQL Server.

    Lessons

    • Integrating with Enterprise Authentication Systems
    • Developing Windows Server-Level Security Policies
    • Developing a Secure Communication Policy
    • Defining SQL Server Security Monitoring Standards
    Module 3: Designing Security Policies for Instances and Databases

    This module explains how to design SQL Server instance-level, database-level, and object-level security policies. This module teaches the security monitoring standards for instances and databases.

    Lessons

    • Designing an Instance-Level Security Policy
    • Designing a Database-Level Security Policy
    • Designing an Object-Level Security Policy
    • Defining Security Monitoring Standards for Instances and Databases
    Module 4: Integrating Data Encryption into a Database Security Design

    This module provides the guidelines and considerations for security data using encryption and certificates. This module also describes various data encryption policies. Finally, this module shows how to determine a key storage method.

    Lessons

    • Securing Data by Using Encryption and Certificates
    • Designing Data Encryption Policies
    • Determining a Key Storage Method
    Module 5: Designing a Security Exceptions Policy

    This module provides guidelines for gathering business and regulatory requirements and comparing them with existing policy. This module also covers how to determine the exceptions and their impact on security.

    Lessons

    • Analyzing Business and Regulatory Requirements
    • Determining the Exceptions and their Impact
    Module 6: Designing a Response Strategy for Threats and Attacks

    This module provides guidelines to respond to virus and worm attacks, denial-of-service attacks, and injection attacks.

    Lessons

    • Designing a Response Policy for Virus and Worm Attacks
    • Designing a Response Policy for Denial-of-Service Attacks
    • Designing a Response Policy for Internal and SQL Injection Attacks
    Posted Jun 16 2007, 02:53 PM by Brett with no comments
    Filed under:
  • Course 2124 - Programming with C#

    Course 2124-Five days-Instructor-led

    Introduction

    The goal of this course is to provide students with the knowledge and skills they need to develop C# applications for the Microsoft .NET Platform. The course focuses on C# program structure, language syntax, and implementation details.

    C# was created to be the programming language best suited for writing enterprise applications for .NET. C# combines the high productivity of Microsoft Visual Basic with the raw power of C++. It is a simple, object-oriented, and type-safe programming language that is based on the C and C++ family of languages.

    Audience

    This course is intended for experienced developers who already have programming experience in C, C++, Visual Basic, or Java. These developers will be likely to develop enterprise business solutions.

    At Course Completion

    At the end of the course, students will be able to:

    • List the major elements of the .NET Framework and explain how C# fits into the .NET Platform.
    • Analyze the basic structure of a C# application and be able to document, debug, compile, and run a simple application.
    • Create, name, and assign values to variables.
    • Use common statements to implement flow control, looping, and exception handling.
    • Create methods (functions and subroutines) that can return values and take parameters.
    • Create, initialize, and use arrays.
    • Explain the basic concepts and terminology of object-oriented programming.
    • Use common objects and reference types.
    • Create, initialize, and destroy objects in a C# application.
    • Build new C# classes from existing classes.
    • Create self-contained classes and frameworks in a C# application.
    • Define operators, use delegates, and add event specifications.
    • Implement properties and indexers.
    • Use predefined and custom attributes.

    Prerequisites

    Before attending this course, students must have:

    • Experience with programming in C, C++, Visual Basic, Java, or another programming language.
    • Familiarity with the Microsoft .NET strategy as described on the Microsoft .NET Web site: http://www.microsoft.com/net/.

    Familiarity with the .NET Framework as described on the MSDN Magazine Web site:

    • http://msdn.microsoft.com/msdnmag/issues/0900/Framework/Framework.asp
    • http://msdn.microsoft.com/msdnmag/issues/1000/Framework2/Framework2.asp

    Course Outline

    Module 1: Overview of the Microsoft .NET Platform

    Take a closer look: Download Sample Module 1 (Portable Document Format, 850 KB).

    The following topics are covered in this module:

    • Introduction to the .NET Platform
    • Overview of the .NET Framework
    • Benefits of the .NET Framework
    • The .NET Framework Components
    • Languages in the .NET Framework
     Module 2: Overview of C#

    Take a closer look: Download Sample Module 2 (Portable Document Format, 953 KB).

    The following topics are covered in this module:

    • Structure of a C# Program
    • Basic Input/Output Operations
    • Recommended Practices
    • Compiling, Running, and Debugging
     Module 3: Using Value-Type Variables

    The following topics are covered in this module:

    • Common Type System
    • Naming Variables
    • Using Built-In Data Types
    • Creating User-Defined Data Types
    • Converting Data Types
    Module 4: Statements and Exceptions

    The following topics are covered in this module:

    • Introduction to Statements
    • Using Selection Statements
    • Using Iteration Statements
    • Using Jump Statements
    • Handling Basic Exceptions
    • Raising Exceptions
    Module 5: Methods and Parameters

    The following topics are covered in this module:

    • Using Methods
    • Using Parameters
    • Using Overloaded Methods
    Module 6: Arrays

    The following topics are covered in this module:

    • Overview of Arrays
    • Creating Arrays
    • Using Arrays
     Module 7: Essentials of Object-Oriented Programming

    The following topics are covered in this module:

    • Classes and Objects
    • Using Encapsulation
    • C# and Object Orientation
    • Defining Object-Oriented Systems
    Module 8: Using Reference-Type Variables

    The following topics are covered in this module:

    • Using Reference-Type Variables
    • Using Common Reference Types
    • The Object Hierarchy
    • Namespaces in the .NET Framework
    • Data Conversions
    Module 9: Creating and Destroying Objects

    The following topics are covered in this module:

    • Using Constructors
    • Initializing Data
    • Objects and Memory
    • Resource Managements
    Module 10: Inheritance in C#

    The following topics are covered in this module:

    • Deriving Classes
    • Implementing Methods
    • Using Sealed Classes
    • Using Interfaces
    • Using Abstract Classes
    Module 11: Aggregation, Namespaces, and Advanced Scope

    The following topics are covered in this module:

    • Using Internal Classes, Methods, and Data
    • Using Aggregation
    • Using Namespaces
    • Using Modules and Assemblies
    Module 12: Operators and Events

    The following topics are covered in this module:

    • Introduction to Operators
    • Operator Overloading
    • Creating and Using Delegates
    • Defining and Using Events
    Module 13: Properties and Indexers

    The following topics are covered in this module:

    • Using Properties
    • Using Indexers
    Module 14: Attributes

    The following topics are covered in this module:

    • Overview of Attributes
    • Defining Custom Attributes
    • Retrieving Attribute Values
    Posted Jun 16 2007, 02:53 PM by Brett with no comments
    Filed under: ,
  • Development track courses for .NET 2.0 framework

    Recently I have been asked by many people to advice on what courses and sequence of courses they should do. This is actually a complex question as there are many different paths one could take depending on one's needs. Hopefully this will help you in your decision path.

    Step 1 – Choose Language

    Choose a language that you would like to develop in, either C# (pronounced C-sharp) or Visual Basic .NET. This is a personal choice based on your experience in programming and where you would like to market yourself.

    Some guidelines for choosing the language

    • C++ or Java programmers may wish to go for C# as the syntax is very close.
    • Visual Basic may wish to move to Visual Basic .NET.
    • What are current systems within the company written in
    • What is the general skill base of the company?
    • What skills are in demand in your region?
    • What is the job market like?

    Step 2 – Choose Technology Path

    In your career path, you can specialize in one or more of the following

    Web Developer

    As a web developer you will be learning to develop interactive web based solutions for small and large scale solutions. This is a very exciting choice and a lot of other dependent technologies you should learn before taking this path.

    Windows Developer

    As a windows developer you will be creating windows (form) applications that run on desktops as either thin, smart or fat clients.

    Distributed / Enterprise Application Developer

    As a Web and Windows developer you will be focusing on the user interface aspect of an application, however as a distributed / enterprise application developer the focus is on the backend of the application, this includes web services, transactions, message queuing, serialization, SOAP, WSE and more.

    Some guidelines

    • If you are just starting out in development, you may wish to either shows web or windows based development to get a grasp of the technologies.
    • Distributed / Enterprise Applications should only be attempted when you have sufficient programming background.
    • Do you want to develop front-end or back-end components, i.e. Do you like user interfaces or the business logic and processing?

    Step 3 – Choosing development or design path

    Your third choice is to determine whether you want to understand the technology in order to program solutions put forward by designers or whether you want to design solutions. Should you wish to do the work and code, follow the Microsoft Certified Technology Specialist route. However, if you are interested in designing and proposing solutions, you must first do the Microsoft Certified Technology Specialist track and then the Microsoft Certified Professional Developer track.

    Some guidelines

    • If you are just starting out, consider the MCTS route
    • If you are a designer, system analyst or architect, first learn your technology by doing the MCTS track then focus on design.
    • Have a good development working experience before going the designing route.

    Microsoft Certified Technology Specialist

    The Microsoft Certified Technology Specialist (MCTS) is aimed to highlight your knowledge in as specific are of the .NET 2.0 framework and the technology. It is more aimed at programmers that need to demonstrate technical knowledge. There are three certification paths for the MCTS certification, you choice depends on what technology you predominantly want to specialize in, these are

    • Technology Specialist: .NET Framework 2.0 Web Applications
    • Technology Specialist: .NET Framework 2.0 Windows Applications
    • Technology Specialist: .NET Framework 2.0 Distributed Applications

    The Microsoft Certified Professional Developer

    The Microsoft Certified Professional Developer (MCDP) certification is aimed to more of a designer role where you need to choose the appropriate technology when designing a solution. It is thus aimed more for enterprise developers \ system analysts \ architects and senior programmers. The certification thus focuses more on a job role than a technology specialist. Again there are the three paths to your certification track.

    • Professional Developer: Web Developer
    • Professional Developer: Windows Developer
    • Professional Developer: Enterprise Applications Developer

    Step 4 – Choosing your courses

    Now is the easy part, book and attend courses, study like mad and write exams. Below is a suggested sequence you should do the courses in.

    Some guidelines

    • Don't do advance courses before you have done the introduction courses.
    • Look at the course prerequisites and make sure you meet them before booking on a course, if you are unsure ask!
    • If you have worked on other technologies that are similar and not on .NET, don't skip the basics.
    • Make sure can access the Microsoft Developer Network (MSDN) to learn syntax.

    New to programming

    TBA

    Learning your language

    C#

    Visual Basic .NET

    2124 – Programming with C#

    TBA

       
       
       

    Database programming (optional on all tracks)

    As the majority of programmers employed in the commercial development sector will be interacting with databases, it is strongly recommended that you attend some database courses before resuming the track.

    Web / Windows / Distributed

    2071 - Querying Microsoft SQL Server 2000 with Transact-SQL more...

    2500 - Introduction to XML and the Microsoft .NET Platform more...

    2779 - Implementing a Microsoft SQL Server 2005 Database more...

    2780 - Maintaining a Microsoft SQL Server 2005 Database more...

    2782 - Microsoft SQL Server 2005 Databases more...

    ADO.NET (all tracks)

    Once you have learnt how to query and interact with a database, your next set of courses should be around data access through the .NET framework. The following courses are not language specific and cater for both VB.NET and C# programmers.

    Web / Windows / Distributed

    Workshop 2541: Core Data Access with Microsoft Visual Studio 2005 more...

    Workshop 2542: Advanced Data Access with Microsoft Visual Studio 2005 more...

    Core technology (choose track)

    The following courses are not language specific and cater for both VB.NET and C# programmers.

    Web

    Windows

    Distributed

    HTML

    Workshop 2546: Core Windows Forms Technologies with Microsoft Visual Studio 2005 (Three days) more...

    2500 - Introduction to XML and the Microsoft .NET Platform more... (Manditory)

    Java Script

    Workshop 2547: Advanced Windows Forms Technologies with Microsoft Visual Studio 2005 (Two days) more...

    Workshop 2548: Core Distributed Application Development with Microsoft Visual Studio 2005 (three days) more...

    Workshop 2543: Core Web Application Technologies with Microsoft Visual Studio 2005 (Three days) more...

     

    Workshop 2549: Advanced Distributed Application Development with Microsoft Visual Studio 2005 (three days) more...

    Workshop 2544: Advanced Web Application Technologies with Microsoft Visual Studio 2005 (Two days) more...

       
         

    Microsoft Certified Technology Specialist Exams

    After doing the above courses in your chosen track and bit of prep, your are now read to write the MCTS Exams

    Web

    Windows

    Distributed

    Exam 70–536: TS: Microsoft .NET Framework 2.0 - Application Development Foundation

    Exam 70-536: TS: Microsoft .NET Framework 2.0 – Application Development Foundation

    Exam 70–536: TS: Microsoft .NET Framework 2.0 – Application Development Foundation

    Exam 70–528: TS: Microsoft .NET Framework 2.0 - Web-Based Client Development

    Exam 70-526: TS: Microsoft .NET Framework 2.0 – Windows-Based Client Development

    Exam 70–529: TS: Microsoft .NET Framework 2.0 – Distributed Application Development

    Courses for Designer

    The following courses are for programmers, system analysts, architects that will be proposing and designing solutions. These course also prepare one for the Microsoft Certified Professional Developer certification.

    Web

    Windows

    Distributed

    MCTP Courses

    MCTP Courses

    MCTP Courses

    TBA

    TBA

    TBA

    Microsoft Certified Professional Developer Exams

    After a bit of prep and the MCDP exam you should be able to write the following exams

    Web

    Windows

    Distributed

    MCTS Exams

    MCTS Exams

    MCTS Exams

    Exam 70-547: PRO: Designing and Developing Web Applications by Using the Microsoft .NET Framework

    Exam 70–548: PRO: Designing and Developing Windows Applications by Using the Microsoft .NET Framework

    Exam 70–549: PRO: Designing and Developing Enterprise Applications by Using the Microsoft .NET Framework

    Exam 70–536: TS: Microsoft .NET Framework 2.0 - Application Development Foundation

    Exam 70–536: TS: Microsoft .NET Framework 2.0 - Application Development Foundation

    Exam 70–536: TS: Microsoft .NET Framework 2.0 - Application Development Foundation

    Exam 70-528: TS: Microsoft .NET Framework 2.0 - Web-Based Client Development

    Exam 70–526: TS: Microsoft .NET Framework 2.0 - Windows-Based Client Development

    Exam 70–526: TS: Microsoft .NET Framework 2.0 - Windows-Based Client Development

       

    Exam 70–528: TS: Microsoft .NET Framework 2.0 - Web-Based Client Development

       

    Exam 70–529: TS: Microsoft .NET Framework 2.0 - Distributed Application Development

    Posted Jun 13 2007, 10:49 PM by Brett with 9 comment(s)
    Filed under:
  • Course 2786 - Designing a Microsoft SQL Server 2005 Infrastructure

    Course 2786: Two days; Instructor-Led

    Introduction

    This two-day instructor-led course provides database administrators working in enterprise environments with the knowledge and skills to design a Microsoft SQL ServerT 2005 database infrastructure. The course focuses on the development of strategies for data archiving, consolidation, distribution, and recovery. The course also stresses the importance of capacity analysis and emphasizes the tradeoffs that need to be made during design.

    This is the first course in the database administration curriculum and will serve as the entry point for other courses in the curriculum.

    Audience

    This course is intended for current professional database administrators who have three or more years of on-the-job experience administering SQL Server database solutions in an enterprise environment.

    At Course Completion

    After completing this course, students will be able to:

    • Analyze storage, CPU, memory, and network capacity needs.
    • Design a strategy for data archiving.
    • Design a strategy for database server consolidation.
    • Design a strategy for data distribution.
    • Design a database server infrastructure.
    • Design a strategy for data recovery.
    • Establish database conventions and standards.

    Prerequisites

    Before attending this course, students must:

    • Understand the tradeoffs among the different redundant storage types. For example, what RAID levels mean, and how they differ from Storage Area Networks (SAN).
    • Understand how replication works and how replication is implemented.
    • Be familiar with reading user requirements and business-need documents. For example, development project vision/mission statements or business analysis reports.
    • Have some knowledge of how queries execute. Must be able to read a query execution plan and understand what is happening.
    • Have basic knowledge of the dependencies between system components.
    • Be able to design a database to third normal form (3NF) and know the tradeoffs when backing out of the fully normalized design (denormalization) and designing for performance and business requirements in addition to being familiar with design models, such as Star and Snowflake schemas.
    • Have monitoring and troubleshooting skills.
    • Have knowledge of the operating system and platform. That is, how the operating system integrates with the database, what the platform or operating system can do, and how the interaction between the operating system and the database works. For example, how integrated authentication interacts with Active Directory directory service.
    • Have knowledge of application architecture. That is, how applications can be designed in three layers, what applications can do, interaction between applications and the database, interaction between the database and the platform or operating system.
    • Must already know how to use:
    • o A data modeling tool
    • o Microsoft Office Visio (to create infrastructure diagrams)
    • Be familiar with SQL Server 2005 features, tools, and technologies.
    • Have a Microsoft Certified Technology Specialist: Microsoft SQL Server 2005 credential or equivalent experience.

     In addition, it is recommended, but not required, that students have completed:

    • Course 2778: Writing Queries Using Microsoft SQL Server 2005 Transact-SQL.
    • Course 2779: Implementing a Microsoft SQL Server 2005 Database.
    • Course 2780: Maintaining a Microsoft SQL Server 2005 Database.

    Course Outline

    Module 1: Analyzing Capacity Needs

    This module explains how to gather data about the current capacity of key system resources such as storage, CPU, memory, and network bandwidth. It also explains how the resulting data can be used to estimate future capacity needs.

    Lessons

    • Estimating Storage Requirements
    • Estimating CPU Requirements
    • Estimating Memory Requirements
    • Estimating Network Requirements
    Module 2: Designing a Strategy for Data Archiving

    This module explains how to identify the requirements that affect data archiving, determine the structure of archival data, select an appropriate storage format, and develop a data movement strategy. It also describes the key elements of a data archival plan and the process of creating it.

    Lessons

    • Identifying Requirements that Affect Data Archiving
    • Determining the Structure of Archival Data
    • Creating a Data Archival Plan
    Module 3: Designing a Strategy for Database Server Consolidation

    This module describes the benefits of consolidating database servers in various ways and explains how to use multiple SQL Server instances to optimize the design of a database server infrastructure. It also details the process of designing a database server consolidation plan.

    Lessons

    • Overview of Database Server Consolidation
    • Designing a Strategy for SQL Server Instances
    • Designing a Database Server Consolidation Plan
    Module 4: Designing a Strategy for Data Distribution

    This module describes the various tools that are provided by SQL Server 2005 for data distribution and explains how to select an appropriate tool based on the requirements of an organization. It also details the process of creating a data distribution plan specifically for replication.

    Lessons

    • Overview of Data Distribution
    • Creating a Data Distribution Plan Using Replication
    Module 5: Designing a Database Server Infrastructure

    This module explains how to evaluate the current database server infrastructure of an organization and gather requirements for modifying it. It also provides guidelines and best practices for designing modifications to the current infrastructure and describes the hardware and software tradeoffs involved in the design process.

    Lessons

    • Evaluating the Current Database Server Infrastructure
    • Gathering Requirements for Changing a Database Server Infrastructure
    • Designing Modifications to a Database Server Infrastructure
    Module 6: Designing a Strategy for Data Recovery

    This module explains how to create a backup and recovery strategy. It also describes the key components of a database disaster recovery plan and the process of creating it.

    Lessons

    • Creating a Backup and Restore Strategy
    • Creating a Database Disaster Recovery Plan
    Module 7: Establishing Database Conventions and Standards

    This module describes how well a database naming convention simplifies administration, and provides guidelines for establishing such a convention. It also explains how to define Transact-SQL coding, database access, and deployment process standards.

    Lessons

    • Establishing Database Naming Conventions
    • Defining Database Standards
    Posted Jun 12 2007, 04:02 PM by Brett with no comments
    Filed under:
  • Course 2784 - Tuning and Optimizing Queries using Microsoft SQL Server 2005

    Course 2784A: Three days; Instructor-Led Course Syllabus

    Introduction

    This three-day instructor-led workshop provides database developers working in enterprise environments using Microsoft SQL Server 2005 the knowledge and skills to evaluate and improve queries and query response times. The workshop focuses on systematic identification and optimization of database factors that impact query performance.

    Audience

    This course is intended for current professional database developers who have three or more years of on-the-job experience developing SQL Server database solutions in an enterprise environment.

    At Course Completion

    After completing this course, students will be able to:

    • Normalize databases.
    • Design a normalized database.
    • Optimize a database design by denormalizing.
    • Optimize data storage.
    • Manage concurrency
    • Manage concurrency by selecting the appropriate transaction isolation level.
    • Select a locking granularity level.
    • Optimize and tune queries for performance.
    • Optimize an indexing strategy.
    • Decide when cursors are appropriate.
    • Identify and resolve performance-limiting problems.

    Prerequisites

    Before attending this course, students must:

    • Have working knowledge of data storage. Specifically, knowledge about row layout, fixed length field placement and varying length field placement.
    • Be familiar with index structures and index utilization. Specifically, they must understand the interaction between non-clustered indexes, clustered indexes and heaps. They must know why a covering index can improve performance.
    • Have had hands-on database developer experience. Specifically, three years of experience as a full-time database developer in an enterprise environment.
    • Be familiar with the locking model. Specifically, students should have an understanding of lock modes, lock objects and isolation levels and be familiar with process blocking.
    • Understand Transact-SQL syntax and programming logic. Specifically, students should be completely fluent in advanced queries, aggregate queries, subqueries, user-defined functions, cursors, control of flow statements, CASE expressions, and all types of joins.
    • Be able to design a database to third normal form (3NF) and know the trade offs when backing out of the fully normalized design (denormalization) and designing for performance and business requirements in addition to being familiar with design models, such as Star and Snowflake schemas.
    • Have strong monitoring and troubleshooting skills, including using monitoring tools.
    • Have basic knowledge of the operating system and platform. That is, how the operating system integrates with the database, what the platform or operating system can do, and how interaction between the operating system and the database works.
    • Have basic knowledge of application architecture. That is, how applications can be designed in three layers, what applications can do, how interaction between the application and the database works, and how the interaction between the database and the platform or operating system works.
    • Know how to use a data modeling tool.
    • Be familiar with SQL Server 2005 features, tools, and technologies.
    • Have a Microsoft Certified Technology Specialist: Microsoft SQL Server 2005 credential - or equivalent experience.

     In addition, it is recommended, but not required, that students have completed:

    • Course 2778, Writing Queries Using Microsoft SQL Server 2005 Transact-SQL.
    • Course 2779, Implementing a Microsoft SQL Server 2005 Database.
    • Course 2780, Maintaining a Microsoft SQL Server 2005 Database.

    Course Outline

    Unit 1: Measuring Database Performance

    This unit provides students with an opportunity to measure database performance and identify database performance bottlenecks. Students will use a sample script to identify performance and concurrency problems, capture baseline performance, and prioritize identified problems for optimization.

    Topics

    • Importance of Benchmarking
    • Key Measures for Query Performance: Sysmon
    • Key Measures for Query Performance: Profiler
    • Guidelines for Identifying Locking and Blocking
     Unit 2: Optimizing Physical Database Design

    In this unit, students work with strategies for optimizing physical database design. Students will optimize a database schema using normalization, generalization, and denormalization.

    Topics

    • Performance Optimization Model
    • Schema Optimization Strategy: Keys
    • Schema Optimization Strategy: Responsible Denormalization
    • Schema Optimization Strategy: Generalization
    Unit 3: Optimizing Queries for Performance

    In this unit students experience optimizing and tuning queries to improve performance. In the lab, students will optimize stored procedures, views, and non-cursor aggregate queries to improve database performance and user experience.

    Each query that is optimized improves the overall system because the query will use fewer resources, freeing up those resources for other queries, and reducing the amount of locking done by the query. The domino effect is profound.

    Topics

    • Performance Optimization Model: Queries
    • What Is Query Logical Flow?
    • Considerations for Using Subqueries
    • Guidelines for Building Efficient Queries
    Unit 4: Refactoring Cursors into Queries

    In this unit, students will work with strategies for refactoring cursors into queries. In the lab, students will work to optimize a database by replacing slow iterative code with faster set-based code.

    Topics

    • Performance Optimization Model: Query-Set-based solutions
    • Five Steps to Building a Cursor
    • Strategies for Refactoring Cursors
    Unit 5: Optimizing an Indexing Strategy

    In this unit, students will work on optimizing indexing strategies. Students will work with a given database to add and delete indexes, by providing the optimum bridge between the query and the data without any redundancies.

    Topics

    • Performance Optimization Model: Indexes
    • Considerations for Using Indexes
    • Best Uses of the Clustered Index
    • Best Practices for Non-Clustered Index Design
    • How to Document an Indexing Strategy
    Unit 6: Managing Concurrency

    This unit provides students with the opportunity to work with concurrency management. Students will look for concurrency issues and then solve them by optimizing transactions and adjusting the transaction isolation level.

    Topics

    • Performance Optimization Model: Locking and Blocking
    • Multimedia - "How to Use Efficient Queries to Reduce Locking and Blocking"
    • Strategies to Reduce Locking and Blocking
    Posted Jun 12 2007, 04:02 PM by Brett with no comments
    Filed under:
  • Clinic 2783 - Designing the Data Tier for Microsoft SQL Server 2005

    Clinic 2783: One days; Instructor-Led

    Introduction

    This one-day instructor-led clinic provides students with the knowledge and skills to design the data tier for Microsoft SQL Server 2005. The clinic focuses on teaching database developers working in enterprise environments to understand and decide how application developers are going to access and consume their data. This is a major failure point of database solutions today.

    Audience

    This clinic is intended for current professional database developers who have three or more years of on-the-job experience developing SQL Server database solutions in an enterprise environment.

    At Clinic Completion

    After completing this clinic, students will be able to:

    • Choose data access technologies and an object model to support an organization's business needs.
    • Design an exception handling strategy.
    • Choose a cursor strategy.
    • Design query strategies using Multiple Active Result Sets (MARS).
    • Design caching strategies for database applications.
    • Design a scalable data tier for database applications.

    Prerequisites

    Before attending this clinic, students must:

    • Have experience reading user requirements and business-need documents. For example, development project vision/mission statements or business analysis reports.
    • Have basic knowledge of the Microsoft .NET Framework, .NET concepts, ADO.NET, and service oriented architecture (SOA).
    • Be familiar with the tasks that application developers typically perform.
    • Understand Transact-SQL syntax and programming logic.
    • Have some experience with professional-level database design and know the tradeoffs when backing out of the fully normalized design (denormalization) and designing for performance and business requirements, in addition to being familiar with design models such as Star and Snowflake schemas.
    • Have basic monitoring and troubleshooting skills. Specifically, how to use SQL Profiler and dynamic management views.
    • Have basic knowledge of the operating system and platform. That is, how the operating system integrates with the database, what the platform or operating system can do, and how interaction between the operating system and the database works.
    • Have basic knowledge of application architecture. That is, how applications can be designed in three layers, what applications can do, how interaction between the application and the database works, and how the interaction between the database and the platform or operating system works.
    • Know how to use a data modeling tool.
    • Be familiar with SQL Server 2005 features, tools, and technologies.
    • Have a Microsoft Certified Technology Specialist: Microsoft SQL Server 2005 credential, or equivalent experience.

    In addition, it is recommended, but not required, that students have completed:

    • Course 2778: Writing Queries Using Microsoft SQL Server 2005 Transact-SQL.
    • Course 2779: Implementing a Microsoft SQL Server 2005 Database.
    • Course 2780: Maintaining a Microsoft SQL Server 2005 Database.

    Clinic Outline

    Session 1: Choosing Data Access Technologies and an Object Model

    This session explains how to choose data access technologies and an object model to support an organization's business needs.

    Sections

    • Introduction to Data Access Technologies
    • Choosing Technologies for Accessing Data
    • Building a Data Access Layer
    • Designing Data Access from SQL Common Language Runtime (CLR) Objects
    • Available Data Object Models for Administering SQL Server
    Session 2: Designing an Exception Handling Strategy

    This session describes the various types of exceptions that can occur in a database system, how to capture them, and how to manage them appropriately.

    Sections

    • Exception Types and Their Purposes
    • Detecting Exceptions
    • Managing Exceptions
    Session 3: Choosing a Cursor Strategy

    This session describes when cursors are appropriate and how to use them to optimize the use of system resources.

    Sections

    • Common Scenarios for Row-Based vs. Set-Based Operations
    • Selecting Appropriate Server-Side Cursors
    • Selecting Appropriate Client-Side Cursors
    Session 4: Designing Query Strategies Using Multiple Active Result Sets

    This session describes when Multiple Active Result Sets (MARS) can improve application response time and user satisfaction.

    Sections

    • Introduction to MARS
    • Designing Query Strategies for Multiple Reads
    • Designing Query Strategies for Mixing Reads and Writes in the Same Connection
    • Concurrency Considerations When Using MARS
    Session 5: Designing Caching Strategies for Database Applications

    This session describes how to optimize system resources by caching data and objects in the appropriate layers.

    Sections

    • Why Caching Is Important
    • Data and Query Caching in SQL Server 2005
    • Using Caching Technologies Outside of SQL Server
    • Custom Caching Techniques
    Session 6: Designing a Scalable Data Tier for Database Applications

    This session describes how to assess scalability needs and design the best architecture to scale the system to meet those needs.

    Sections

    • Identifying the Need to Scale
    • Scaling Database Applications to Avoid Concurrency Contention
    • Scaling SQL Server Database Systems
    • Scaling Database Applications Using a Service-Oriented Architecture
    • Improving Availability and Scalability by Scaling Out Front-End Systems
    Posted Jun 12 2007, 04:02 PM by Brett with no comments
    Filed under:
  • Course 2782 - Designing Microsoft SQL Server 2005 Databases

    Course 2782: Two days; Instructor-Led

    Introduction

    This two-day instructor-led course provides students with the knowledge and skills to design databases for Microsoft SQL Server 2005 using business requirements to guide their decisions (beyond structured third normal form [3NF] modeling techniques). Students will also learn to incorporate security requirements throughout their design.

    Audience

    This course is intended for current professional database developers who have three or more years of on-the-job experience developing SQL Server database solutions in an enterprise environment.

    At Course Completion

    After completing this course, students will be able to:

    • Approach database design from a systematic perspective, gather database requirements, and formulate a conceptual design.
    • Analyze and evaluate a logical database design.
    • Apply best practices for creating a physical database design.
    • Apply best practices when designing for database scalability.
    • Design a database access strategy.
    • Use best practices to model database dependencies.

    Prerequisites

    Before attending this course, students must:

    • Have experience reading user requirements and business-need documents. For example, development project vision/mission statements or business analysis reports.
    • Have experience reading and drawing business process flow charts.
    • Have experience reading and drawing entity relationship (ER) diagrams.
    • Understand Transact-SQL syntax and programming logic.
    • Be able to design a database to 3NF and know the tradeoffs when backing out of the fully normalized design (denormalization) and designing for performance and business requirements in addition to being familiar with design models, such as Star and Snowflake schemas.
    • Have basic monitoring and troubleshooting skills.
    • Have basic knowledge of the operating system and platform. That is, how the operating system integrates with the database, what the platform or operating system can do, and how interaction between the operating system and the database works.
    • Have basic knowledge of application architecture. That is, how applications can be designed in three layers, what applications can do, how interaction between the application and the database works, and how the interaction between the database and the platform or operating system works.
    • Know how to use a data modeling tool.
    • Be familiar with SQL Server 2005 features, tools, and technologies.
    • Have a Microsoft Certified Technology Specialist: Microsoft SQL Server 2005 credential, or equivalent experience.

    In addition, it is recommended, but not required, that students have completed:

    • Course 2778: Writing Queries Using Microsoft SQL Server 2005 Transact-SQL.
    • Course 2779: Implementing a Microsoft SQL Server 2005 Database.
    • Course 2780: Maintaining a Microsoft SQL Server 2005 Database.

    Course Outline

    Module 1: Approaching Database Design Systematically

    This module explains how to acquire the skills to approach database design with a systematic perspective. A systematic approach involves formulating your database design process, following guidelines on how to gather and document database requirements, and following best practices when formulating a conceptual design.

    Lessons

    • Overview of Database Design
    • Gathering Database Requirements
    • Creating a Conceptual Database Design
    Module 2: Modeling a Database at the Logical Level

    This module explains the best practices followed when you build a new logical database model. You will also learn the guidelines for normalization when designing an OLTP model and when designing a data warehouse database. Finally, you will learn to evaluate the existing logical model of a database.

    Lessons

    • Building a Logical Database Model
    • Designing for OLTP Activity
    • Designing for Data Warehousing
    • Evaluating Logical Models
    Module 3: Modeling a Database at the Physical Level

    This module explains the guidelines to be followed when designing physical database objects and constraints. The module also covers the best practices for designing database security and for designing database and server options. Finally, this module covers the best practices for evaluating the physical model.

    Lessons

    • Designing Physical Database Objects
    • Designing Constraints
    • Designing for Database Security
    • Designing Server and Database Options
    • Evaluating the Physical Model
    Module 4: Designing for Database Performance

    This module explains the best practices to be followed for designing indexes. The module also covers the guidelines for planning table optimization, and choosing additional optimization techniques.

    Lessons

    • Designing Indexes
    • Planning for Table Optimization
    • Planning for Database Optimization
    Module 5: Designing a Database Access Strategy

    This module explains the best practices to be followed when designing for secure data access. The module also covers the guidelines for designing user-defined functions. Finally, this module explains the best practices for designing stored procedures.

    Lessons

    • Designing for Secure Data Access
    • Designing User-Defined Functions
    • Designing Stored Procedures
    Module 6: Modeling Database Dependencies

    This module explains guidelines for modeling local database dependencies. This module also covers the guidelines for modeling remote database dependencies.

    Lessons

    • Modeling Local Database Dependencies
    • Modeling Remote Database Dependencies
    Posted Jun 12 2007, 04:02 PM by Brett with no comments
    Filed under:
  • Course 2781 - Designing Microsoft SQL Server 2005 Server-Side Solutions

    Course 2781: Three days; Instructor-Led

    Introduction

    This three-day instructor-led course provides students with the knowledge and skills to design server-side solutions for Microsoft SQL ServerT 2005. The course focuses on teaching database developers who work in enterprise environments to identify and place database technologies during design to achieve a suitable solution that meets the needs of an organization. Students will also learn to consider the solution from a system-wide view instead of from a single database or server perspective.

    Audience

    This course is intended for current professional database developers who have three or more years of on-the-job experience developing SQL Server database solutions in an enterprise environment.

    At Course Completion

    After attending this course, students will be able to:

    • Select SQL Server services to support an organization's business needs.
    • Design a security strategy for a SQL Server 2005 solution.
    • Design a data modeling strategy.
    • Design a transaction strategy for a SQL Server solution.
    • Design a Notification Services solution.
    • Design a Service Broker solution.
    • Plan for source control, unit testing, and deployment to meet an organization's needs.
    • Evaluate advanced query techniques.
    • Evaluate advanced XML techniques.

    Prerequisites

    Before attending this course, students must:

    • Have experience reading user requirements and business-need documents. For example, development project vision/mission statements or business analysis reports.
    • Understand Transact-SQL syntax and programming logic.
    • Understand XML. Specifically, they must be familiar with the syntax of XML, what elements and attributes are, and how to distinguish them.
    • Understand security requirements. Specifically, must understand how unauthorized users can gain access to sensitive information and be able to plan strategies to prevent access.
    • Be able to design a database to 3NF and know the tradeoffs when backing out of the fully normalized design (denormalization) and designing for performance and business requirements in addition to being familiar with design models, such as Star and Snowflake schemas.
    • Have basic monitoring and troubleshooting skills.
    • Have basic knowledge of the operating system and platform. That is, how the operating system integrates with the database, what the platform or operating system can do, and how interaction between the operating system and the database works.
    • Have basic knowledge of application architecture. That is, how applications can be designed in three layers, what applications can do, how interaction between the application and the database works, and how the interaction between the database and the platform or operating system works.
    • Have some experience with a reporting tool.
    • Be familiar with SQL Server 2005 features, tools, and technologies.
    • Have a Microsoft Certified Technology Specialist: Microsoft SQL Server 2005 credential, or equivalent experience.

    In addition, it is recommended, but not required, that students have completed:

    • Course 2778: Writing Queries Using Microsoft SQL Server 2005 Transact-SQL.
    • Course 2779: Implementing a Microsoft SQL Server 2005 Database.
    • Course 2780: Maintaining a Microsoft SQL Server 2005 Database.

    Course Outline

    Module 1: Selecting SQL Server Services to Support Business Needs

    This module provides an overview of SQL Server 2005 architecture and the various considerations for choosing SQL Server services to include in a solution. The module also describes considerations for using the database enhancements in SQL Server 2005.

    Lessons

    • Overview of the Built-in SQL Server Services
    • Evaluating When to Use the New SQL Server Services
    • Evaluating the Use of Database Engine Enhancements
    Module 2: Designing a Security Strategy

    This module describes the considerations for designing a security strategy for the various components of a SQL Server 2005 solution. This includes considerations for choosing authentication and authorization strategy for a solution, as well as designing security for the solution components such as Notification Services and Service Broker. The module also teaches students the guidelines for designing objects to manage application access. The module provides students with the required knowledge to create an auditing strategy for a database solution. Finally, the module teaches students how to manage security for multiple development teams.

    Lessons

    • Overview of Authentication Modes and Authorization Strategies
    • Designing a Security Strategy for Components of a SQL Server 2005 Solution
    • Designing Objects to Manage Application Access
    • Creating an Auditing Strategy
    • Managing Multiple Development Teams Using the SQL Server 2005 Security Features
    Module 3: Designing a Data Modeling Strategy

    In this module, students learn the various considerations and guidelines to define standards for storing XML data in a solution. The module also provides the knowledge required to design a database schema. The module provides information about the considerations for implementing OLTP and OLAP functionality, considerations for determining normalization levels, and considerations for creating indexes. Finally, the module covers the various considerations for designing a scale-out strategy for a solution.

    Lessons

    • Defining Standards for Storing XML Data in a Solution
    • Designing a Database Solution Schema
    • Designing a Scale-Out Strategy
    Module 4: Designing a Transaction Strategy for a SQL Server 2005 Solution

    This module describes considerations and guidelines for defining a transaction strategy for a solution. It also shows how to define data behavior requirements and specify isolation levels for data stores.

    Lessons

    • Defining Data Behavior Requirements
    • Defining Isolation Levels
    • Designing a Resilient Transaction Strategy
    Module 5: Designing a Notification Services Solution

    This module describes the guidelines and processes for designing a Notification Services solution as part of an overall SQL Server 2005 solution. It shows how to define event data and how to store this data, how to design a subscription strategy for a Notification Services solution, how to design a notification strategy, and how to design a notification delivery strategy.

    Lessons

    • Defining Event Data
    • Designing a Subscription Strategy
    • Designing a Notification Strategy
    • Designing a Notification Delivery Strategy
    Module 6: Designing a Service Broker Solution

    This module describes the guidelines and processes for designing a Service Broker solution as part of an overall SQL Server 2005 solution. It covers tasks such as designing the Service Broker solution architecture, designing the Service Broker data flow, and designing Service Broker solution availability.

    Lessons

    • Designing a Service Broker Solution Architecture
    • Designing Service Broker Data Flow
    • Designing Service Broker Solution Availability
    Module 7: Planning for Source Control, Unit Testing, and Deployment

    This module teaches the guidelines and considerations for planning for source control, unit testing, and deployment, during the design of a SQL Server 2005 solution. Design tasks covered include designing a source control strategy, designing a unit testing plan, creating a performance baseline and benchmarking strategy, and designing a deployment strategy.

    Lessons

    • Designing a Source Control Strategy
    • Designing a Unit Test Plan
    • Creating a Performance Baseline and Benchmarking Strategy
    • Designing a Deployment Strategy
    Module 8: Evaluating Advanced Query and XML Techniques

    This module teaches students how to evaluate queries using the advanced query and XML techniques, which students might require when designing a SQL Server 2005 solution. Query tasks include evaluating common table expressions, pivot queries, and ranking techniques. XML tasks include defining standards for storing XML data, evaluating the use of XQuery, and creating a strategy for converting data between XML and relational formats.

    Lessons

    • Evaluating Common Table Expressions
    • Evaluating Pivot Queries
    • Evaluating Ranking Queries
    • Overview of XQuery
    • Overview of Strategies for Converting Data Between XML and Relational Formats
    Posted Jun 12 2007, 04:02 PM by Brett with no comments
    Filed under:
  • Course 2780 - Maintaining a Microsoft SQL Server 2005 Database

    Course 2780B: Five days; Instructor-Led

    Introduction

    This five-day instructor-led course provides students with the knowledge and skills to maintain a Microsoft SQL Server 2005 database. The course focuses on teaching individuals how to use SQL Server 2005 product features and tools related to maintaining a database.

    Audience

    This course is intended for IT Professionals who want to become skilled on SQL Server 2005 product features and technologies for maintaining a database.

    At Course Completion

    After completing this course, students will be able to:

    • Install and configure SQL Server 2005.
    • Manage database files.
    • Backup and restore databases.
    • Manage security.
    • Monitor SQL Server.
    • Transfer data into and out of SQL Server.
    • Automate administrative tasks.
    • Replicate data between SQL Server instances.
    • Maintain high availability.

    Prerequisites

    Before attending this course, students must have:

    • Basic knowledge of the Microsoft Windows operating system and its core functionality.
    • Working knowledge of Transact-SQL.
    • Working knowledge of relational databases.
    • Some experience with database design.

    In addition, it is recommended, but not required, that students have completed:

    • Course 2778: Writing Queries Using Microsoft SQL Server 2005 Transact-SQL.
    • Course 2779: Implementing a Microsoft SQL Server 2005 Database.

    Course Outline

    Module 1: Installing and Configuring SQL Server 2005

    This module explains how to plan for and install SQL Server 2005, how to manage a SQL Server 2005 installation, and how to use the SQL Server 2005 administrative tools.

    Lessons

    • Preparing to Install SQL Server
    • Installing SQL Server 2005
    • Managing a SQL Server 2005 Installation
    Module 2: Managing Databases and Files

    This module explains how to manage databases and files.

    Lessons

    • Planning Databases
    • Creating Databases
    • Managing Databases
    Module 3: Disaster Recovery

    This module explains how to plan and implement a backup and restore strategy.

    Lessons

    • Planning a Backup Strategy
    • Backing Up User Databases
    • Restoring User Databases
    • Performing Online Restore Operations
    • Recovering Data from Database Snapshots
    • System Database and Disaster Recovery
    Module 4: Managing Security

    This module explains how to manage principals, securables, and permissions, and how to implement cryptography in a SQL Server database.

    Lessons

    • Overview of SQL Server Security
    • Protecting the Server Scope
    • Protecting the Database Scope
    • Managing Keys and Certificates in SQL Server
    Module 5: Monitoring SQL Server

    This module explains how to monitor SQL Server performance and activity.

    Lessons

    • Viewing Current Activity
    • Using System Monitor
    • Using SQL Server Profiler
    • Using DDL Triggers
    • Using Event Notifications
    Module 6: Transferring Data

    This module explains how to transfer and transform data.

    Lessons

    • Overview of Data Transfer
    • Introduction to SQL Server Integration Services
    • Using SQL Server Integration Services
    • Features of SQL Server Integration Services
    Module 7: Automating Administrative Tasks

    This module explains how to use the SQL Server Agent to automate administrative tasks.

    Lessons

    • Automating Administrative Tasks in SQL Server 2005
    • Configuring the SQL Server Agent
    • Creating Jobs and Operators
    • Creating Alerts
    • Managing Multiple Servers
    • Managing SQL Server Agent Security
    Module 8: Implementing Replication

    This module explains the purpose of replication, introduces the concepts underpinning replication, and describes how to implement replication in several common scenarios.

    Lessons

    • Overview of Replication
    • Implementing Replication
    • Configuring Replication in Some Common Scenarios
    Module 9: Maintaining High Availability

    This module explains how to implement high availability technologies with SQL Server 2005.

    Lessons

    • Introduction to High Availability
    • Implementing Server Clustering
    • Implementing Database Mirroring
    • Implementing Log Shipping
    • Implementing Peer-to-Peer Replication
    Posted Jun 12 2007, 04:02 PM by Brett with no comments
    Filed under:
  • Course 2779 - Implementing a Microsoft SQL Server 2005 Database

    Course 2779: Five days; Instructor-Led

    Introduction

    This five-day instructor-led course provides students with the knowledge and skills to implement a Microsoft SQL Server 2005 database. The course focuses on teaching individuals how to use SQL Server 2005 product features and tools related to implementing a database.

    Audience

    This course is intended for IT Professionals who want to become skilled on SQL Server 2005 product features and technologies for implementing a database.

    At Course Completion

    After completing this course, students will be able to:

    • Create databases and database files.
    • Create data types and tables.
    • Use XML-related features in Microsoft SQL Server 2005.
    • Plan, create, and optimize indexes.
    • Implement data integrity in Microsoft SQL Server 2005 databases by using constraints.
    • Implement data integrity in Microsoft SQL Server 2005 by using triggers.
    • Implement views.
    • Implement stored procedures.
    • Implement functions.
    • Implement managed code in the database.
    • Manage transactions and locks.
    • Use Service Broker to build a messaging-based solution.
    • Use Notification Services to generate and send notifications.

    Prerequisites

    Before attending this course, students must have:

    • Basic knowledge of the Microsoft Windows operating system and its core functionality.
    • Working knowledge of Transact-SQL.
    • Working knowledge of relational databases.
    • Some experience with database design.

    In addition, it is recommended, but not required, that students have completed:

    • Course 2778: Writing Queries Using Microsoft SQL Server 2005 Transact-SQL.
    • Course 2780: Maintaining a Microsoft SQL Server 2005 Database.

    Course Outline

    Module 1: Creating Databases and Database Files

    This module explains how to create databases, filegroups, schemas, and database snapshots.

    Lessons

    • Creating Databases
    • Creating Filegroups
    • Creating Schemas
    • Creating Database Snapshots
    Module 2: Creating Data Types and Tables

    This module explains how to create data types and tables. It also describes how to create partitioned tables.

    Lessons

    • Creating Data Types
    • Creating Tables
    • Creating Partitioned Tables
    Module 3: Using XML

    This module explains how to use the FOR XML clause and the OPENXML function. It also describes how to use the xml data type and its methods.

    Lessons

    • Retrieving XML by Using FOR XML
    • Shredding XML by Using OPENXML
    • Introducing XQuery
    • Using the xml Data Type
    Module 4: Creating and Tuning Indexes

    This module explains how to plan, create, and optimize indexes. It also describes how to create XML indexes.

    Lessons

    • Planning Indexes
    • Creating Indexes
    • Optimizing Indexes
    • Creating XML Indexes
    Module 5: Implementing Data Integrity by Using Constraints

    This module explains how to implement constraints and provides an overview of data integrity.

    Lessons

    • Data Integrity Overview
    • Implementing Constraints
    Module 6: Implementing Data Integrity by Using Triggers and XML Schemas

    This module explains how to implement triggers and XML schemas.

    Lessons

    • Implementing Triggers
    • Implementing XML Schemas
    Module 7: Implementing Views

    This module explains how to create views.

    Lessons

    • Introduction to Views
    • Creating and Managing Views
    • Optimizing Performance by Using Views
    Module 8: Implementing Stored Procedures

    This module explains how to create stored procedures and functions. It also describes execution plans, plan caching, and query compilation.

    Lessons

    • Implementing Stored Procedures
    • Creating Parameterized Stored Procedures
    • Working With Execution Plans
    • Handling Errors
    Module 9: Implementing Functions

    This module explains how to create functions. It also describes how to control the execution context.

    Lessons

    • Creating and Using Functions
    • Working with Functions
    • Controlling Execution Context
    Module 10: Implementing Managed Code in the Database

    This module explains how to implement managed database objects.

    Lessons

    • Introduction to the SQL Server Common Language Runtime
    • Importing and Configuring Assemblies
    • Creating Managed Database Objects
    Module 11: Managing Transactions and Locks

    This module explains how to use transactions and the SQL Server locking mechanisms to meet the performance and data integrity requirements of your applications.

    Lessons

    • Overview of Transactions and Locks
    • Managing Transactions
    • Understanding SQL Server Locking Architecture
    • Managing Locks
    Module 12: Using Service Broker

    This module explains how to build a messaging-based solution with Service Broker.

    Lessons

    • Service Broker Overview
    • Creating Service Broker Objects
    • Sending and Receiving Messages
    Module 13: Using Notification Services (Optional)

    This module explains how to develop applications that generate and send timely messages to subscribers.

    Lessons

    • Introduction to Notification Services
    • Developing Notification Services Solutions
    Posted Jun 12 2007, 04:02 PM by Brett with no comments
    Filed under:
  • Course 2549 - Advanced Distributed Application Development with Microsoft Visual Studio 2005

    Workshop 2549: Two days; Instructor-Led

    Introduction

    This two-day instructor-led workshop provides students with the knowledge and skills to develop advanced distributed applications using Microsoft Visual Studio 2005. The workshop focuses on advanced features of Web Services Enhancements (WSE) 3.0 and message queuing.

    Audience

    This workshop is intended for corporate or independent software vendor (ISV) application developers who have a desire to learn more about specific technology areas in Microsoft Windows application development.

    At Workshop Completion

    After completing this workshop, students will be able to:

    • Implement WSE 3.0 security and policy
    • Implement WSE 3.0 custom policy assertions
    • Handle large data transfer by using WSE 3.0
    • Implement WSE 3.0 SOAP messaging
    • Implement SOAP headers and extensions
    • Implement WSE 3.0 routing
    • Optimize and protect Microsoft Message Queuing client and server applications

    Prerequisites

    Before attending this workshop, students must:

    • Must have attended or studied Workshop 2548A, Core Distributed Applications or possess equivalent knowledge and skills.
    • Must be able to create Web services.
    • Must be able to write applications that use Web services.
    • Be able to send and receive messages by using Message Queuing

     Workshop Outline

    Unit 1: Implementing WSE 3.0 Security and Policy

    This unit introduces Web Services Enhancements (WSE) 3.0. It explains the Web service WS-* standards implemented by WSE and the WSE 3.0 architecture. The unit also shows how to protect Web services with WSE using policies, encryption, digital signing, and security credentials.

    Lessons

    • What is WSE 3.0 Security?
    • Implementing WSE 3.0 Policies
    Unit 2: Implementing WSE 3.0 Custom Policy Assertions

    This unit introduces the WSE 3.0 custom policy assertion mechanism. It shows the architecture of the custom policy assertions in WSE 3.0 and how to use custom policy assertions in a Web service.

    Lesson

    • What is a WSE 3.0 Custom Policy Assertion?
    • Applying Custom Policy Assertions
    Unit 3: Handling Large Data Transfer by Using WSE 3.0

    This unit describes how to send and receive large files by using WSE 3.0. It discusses the Message Transmission Optimization Mechanism (MTOM) protocol, how to send and receive files, and how to handle bulky data in binary format in SOAP messages.

    Lesson

    • What is the Message Transmission Optimization Mechanism (MTOM)?
    • How to Use MTOM with WSE 3.0
    Unit 4: Implementing WSE 3.0 SOAP Messaging

    This unit describes how to implement SOAP messaging. It describes how to send and receive SOAP messages in Web services by using different sets of protocols.

    Lessons

    • What is SOAP Messaging?
    • Sending and Receiving SOAP Messages
    • TCP and HTTP Messaging
     Unit 5: Implementing SOAP Headers and Extensions

    This unit describes SOAP headers and extensions. It explains what a SOAP header is, and how a Web service processes a SOAP extension.

    Lessons

    • What is a SOAP Header?
    • What is a SOAP Extension?
     Unit 6: Implementing WSE 3.0 Routing

    This unit discusses the routing mechanisms supported in WSE 3.0. It explains how to route Web method calls and how to implement content-based routing.

    Lessons

    • What is Routing?
    • Using WSE 3.0 Routing
    Unit 7: Optimizing and Protecting Message Queuing

    This unit discusses techniques for improving the security and optimizing the performance of applications that use the queuing mechanisms. It also describes how to verify whether messages posted to a queue are delivered successfully and how to correlate a message reply posted to a queue with the original message.

    Lessons

    • How to Reduce Message Queue Bottlenecks
    • How to Verify Message Delivery
    • How to Correlate Message Replies
    • How to Use Encryption and Authentication in Message Queues
    Posted Jun 12 2007, 04:02 PM by Brett with no comments
    Filed under:
  • Course 2548 - Core Distributed Application Development with Microsoft Visual Studio 2005

    Workshop 2548: Three days; Instructor-Led

    Introduction

    This three-day instructor-led workshop provides students with the knowledge and skills to develop distributed applications by using the Microsoft( .NET Framework and Microsoft Visual Studio( 2005. The workshop focuses on building distributed applications by using Web services, remoting, Microsoft Message Queuing, and serviced components.

    Audience

    This workshop is intended for corporate and Independent software vendor application developers who have a desire to learn more about specific technology areas in distributed application development.

    At Workshop Completion

    After completing this workshop, students will be able to:

    • Build and use a Web service.
    • Configure and customize a Web service application.
    • Call Web methods asynchronously.
    • Build remote client and server applications.
    • Create and serialize remoteable types.
    • Manage the lifetime of remote objects.
    • Call remote methods asynchronously.
    • Implement remote events.
    • Send and receive messages by using Microsoft Message Queuing.
    • Create and use serviced components.

    Prerequisites

    Before attending this workshop, students must:

    • Be able to manage a solution environment using the Visual Studio 2005 Integrated development environment (IDE) and tools
    • Understand the Microsoft .NET Framework 2.0 and the Common Language Runtime
    • Be able to program an application by using a .NET Framework 2.0-compliant language
    • Know how to make assemblies available to other applications
    • Have a basic understanding of XML including XML declaration, elements, attributes, and namespaces
    • Have a basic understanding of application domains
    • Have a basic understanding of delegates and events
    • Have a basic understanding of threads

    Course Outline

    Unit 1: Building and Consuming a Simple XML Web Service

    This unit describes how you can create a simple Web service and client application by using the .NET Framework. It also explains how you can configure client proxies, and debug and deploy Web services.

    Lessons

    • Technical Context of Web Services
    • Components of Web Service Technology
    Unit 2: Configuring and Customizing a Web Service

    This unit introduces a number of important configuration and customization options for Web services. It describes how to control the way in which complex parameters to Web methods are serialized. This unit also shows how to use configuration files to control the way in which a Web service operates.

    Lessons

    • XML Serialization
    • How to Use Complex Data Types in Web Services
    • How to Use Attributes to Control Serialization
    • How to Use Service Configuration Attributes
    • Configuration Files
    Unit 3: Calling Web Methods Asynchronously

    This unit explains how to call a Web method asynchronously. It describes how to improve the responsiveness of client applications by avoiding the need to wait for Web methods to complete execution before continuing processing. This unit covers the different options available for calling Web methods asynchronously and it describes how to create one-way methods.

    Lessons

    • The Need for Asynchronous Calls
    • Options for Making Asynchronous Calls
    • One-Way Methods

    Unit 4: Building a Remoting Client and Server

    This unit describes key remoting concepts, and shows how to create a remoting server and client. This unit describes how to use remoting to call methods in remote objects, and how to pass data across remoting boundaries. This unit also shows how to configure and deploy remoting applications.

    Lessons

    • Technical Context of Remoting
    • Remoting Servers and Clients
    • Important Components of Remoting
    Unit 5: Creating and Serializing Remotable Types

    This unit describes how to transfer complex data values across remoting boundaries, and the issues involved in doing so. It compares and contrasts the marshal by value and marshal by reference mechanisms for accessing remote data. This unit also covers version compatibility issues between clients and servers using different versions of a class, and the special requirements for remoting generic classes.

    • Lessons
    • Marshal by Value
    • Marshal by Reference
    • Version Compatibility for Remotable Types
    • Generic Classes
    Unit 6: Performing Remoting Operations Asynchronously

    his unit describes how to call a method asynchronously in the remoting environment. It covers the different techniques you can use and it explains how to raise events in a remoting server and handle them in a client.

    Lessons

    • Asynchronous Methods
    • Calling Remote Methods Asynchronously
    • One-Way Methods
    • Using Events in Remoting Applications
    Unit 7: Managing the Lifetime of Remote Objects

    This unit describes the lifetime of remote objects and how you can control them. This unit introduces the concepts of remote object leases and sponsors. This unit shows how to initialize a remote object's lease to a specific period, and how to renew an object's lease when it expires by using a sponsor.

    Lessons

    • Life Cycle of Remote Objects
    • Lifetime Sponsors
    • Lease Properties
    • Leases and Exception Handling
    Unit 8: Sending and Receiving Messages by Using Message Queuing

    This unit describes how to use Microsoft Message Queuing to build distributed applications. It covers the essential aspects of building client and server applications that use message queues, how to create queues, how to send and receive messages, and how to handle replies to messages. This unit also describes how to access message queues across the Internet.

    Lessons

    • Understanding Message Queuing
    • Creating a Message Queue and Sending a Message
    • Receiving a Message and Posting a Response
    • Using IIS with Message Queuing
    Unit 9: Creating and Consuming Serviced Components

    This unit explains how to build and access serviced components in a .NET Framework application. This unit describes the relationship between .NET Framework serviced components and COM+. It shows how to use the .NET Framework to implement a serviced component that you can register as a COM+ application and how you can write applications that use serviced components.

    Lessons

    • COM+ Services
    • Implementing a Serviced Component
    • Registering a Serviced Component
    • Instantiating a Serviced Component
    Posted Jun 12 2007, 04:02 PM by Brett with no comments
    Filed under:
  • Course 2547 - Advanced Windows Forms Technologies with Microsoft Visual Studio 2005

    Workshop 2547A: Two days; Instructor-Led

    Introduction

    This two-day instructor-led workshop provides students with the knowledge and skills to develop advanced Microsoft Windows Forms applications using Microsoft Visual Studio 2005. The workshop focuses on user interfaces, program structure, and implementation details.

    Audience

    This workshop is intended for corporate or independent software vendor (ISV) application developers who have a desire to learn more about specific technology areas in Windows application development.

    At Workshop Completion

    After completing this workshop, students will be able to:

    • Build MDI applications.
    • Customize Windows Forms and controls.
    • Create customized print components.
    • Perform drag-and-drop operations and implement Clipboard support.
    • Perform asynchronous tasks in Windows Forms by using multithreaded techniques.
    • Enhance the presentation of Windows Forms applications.

    Prerequisites

    Before attending this workshop, students must:

    • Have attended or studied Workshop 2546A, Core Windows Forms Technologies with Visual Studio 2005 or possess equivalent knowledge and skills.
    • Be able to manage a solution environment using the Visual Studio 2005 integrated development environment (IDE) and tools.
    • Be able to program an application using a .NET Framework 2.0 compliant language, including the use of delegates and events.
    • Understand advanced concepts including serialization, reflection, application domains, and multithreading.

     Workshop Outline

    Unit 1: Building MDI Applications

    This unit explains how to create multiple-document interface (MDI) applications that enable one parent window to host multiple documents. It demonstrates how to create MDI parent and child forms and how to determine the active MDI child and work with information on it. It also explains how to implement menu merging in an MDI application to make the menu on the parent form relevant to the active child form.

    Lessons

    • Windows Forms Layout Options
    • What Are MDI Applications?
    Unit 2: Customizing Windows Forms and Controls

    This unit explains how to develop custom Microsoft Windows Forms and controls. Students will learn how to develop user controls, use GDI+ operations, and create new controls that inherit from the Control class. In addition, it demonstrates how to create a nonrectangular Windows Form and how to add features such as attributes and Toolbox bitmaps to controls.

    Lesson

    • What Are the Methods of Authoring Controls for Windows Forms?
    • Ways to Draw a User Interface by Using GDI+
    • Creating a Nonrectangular Windows Form
    Unit 3: Creating Customized Print Components

    This unit explains how to print content from a Microsoft Windows Forms application by using the printing features of GDI+. Students will learn how to keep track of multiple pages when printing and render page content correctly.

    Lesson

    • Printing Features That Are Supported by .NET Framework 2.0
    • Drawing Print Document Content by Using GDI+
    Unit 4: Performing Drag-and-Drop Operations and Implementing Clipboard Support

    This unit introduces the properties, methods, and events that can be used to implement drag-and-drop functionality in a Microsoft Windows Forms application. Students will learn how to start and finish drag-and-drop operations and, specifically, how to implement drag-and-drop operations with a TreeView control. In addition, this unit demonstrates how to use the Clipboard to store and retrieve data.

    Lessons

    • Drag-and-Drop Operations in Windows Forms Applications
    • Adding Clipboard Support in Windows Forms Applications
    Unit 5: Performing Asynchronous Tasks by Using Multithreaded Techniques

    This unit demonstrates how to create Microsoft Windows Forms applications that can run tasks in the background. It explains how to make use of the asynchronous methods and other features of components that support the Asynchronous Pattern for Components. Students will also learn how to use the classes in the System.Threading namespace to run one or more tasks in the background by using multiple threads in an application.

    Lessons

    • Asynchronous Programming in Windows Forms Applications
    • Creating Thread-Safe Applications
    Unit 6: Enhancing the Presentation of Windows Forms Applications

    This unit describes several of the features that can be used when creating professional-looking applications. Students will learn how to build a Windows Form that has the appearance of Microsoft Office Outlook and how to configure a customized master/detail DataGridView control. In addition, this unit explains how to incorporate the PropertyGrid component and application settings features that enable users to edit and save their preferences.

    Lessons

    • Enhancing Application User Interfaces
    • Customizing the DataGridView Control
    • Application Settings and the PropertyGrid Control
    Posted Jun 12 2007, 04:02 PM by Brett with no comments
    Filed under:
  • Course 2546 - Core Windows Forms Technologies with Microsoft Visual Studio 2005

    Workshop 2546: Three days; Instructor-Led

    Introduction

    This three-day instructor-led workshop provides students with the knowledge and skills to develop Microsoft Windows Forms applications using Microsoft Visual Studio 2005. The workshop focuses on user interfaces, program structure, and implementation details.

    Audience

    This workshop is intended for corporate or independent software vendor (ISV) application developers who have a desire to learn more about specific technology areas in Windows application development.

    At Workshop Completion

    After completing this workshop, students will be able to:

    • Create a simple Windows Forms application.
    • Configure standard controls.
    • Build menus.
    • Display and edit data by using data-bound controls.
    • Provide user assistance and enhance usability.
    • Create consistent applications by using dialogs and forms inheritance.
    • Add print and report functionality to a Windows Forms application.
    • Perform asynchronous tasks by using the BackgroundWorker component.
    • Deploy a Windows Forms application by using ClickOnce.

     Prerequisites

    Before attending this workshop, students must:

    • Be able to manage a solution environment using the Visual Studio 2005 integrated development environment (IDE) and tools
    • Understand Microsoft .NET Framework 2.0 and the Common Language Runtime
    • Be able to program an application using a .NET Framework 2.0 compliant language
    • Know how to make assemblies available to other applications
    • Have a basic understanding of XML, including XML declaration, elements, attributes, and namespaces.

    Course Outline

    Unit 1: Creating a Simple Windows Forms Application

    This unit introduces the fundamental skills required to create a simple Windows Forms application. It explains how to configure form properties and how to add controls to a form. It also deals with events and explains how to create event handlers at design time and run time.

    Lessons

    • Components of a Windows Forms User Interface
    • Event Handling in a Windows Forms Application
    Unit 2: Configuring Standard Controls

    This unit introduces many of the controls from the Visual Studio Toolbox. It teaches how to add and configure these controls and explains how to group them into different categories by function.

    Lesson

    • Windows Forms Controls by Function
    Unit 3: Building Menus

    This unit introduces the MenuStrip control and the ContextMenuStrip component. It explains how to create and configure form menus and context menus in an application. It also deals with the ToolStripItems that can be added to the container of a MenuStrip or ContextMenuStrip.

    Lesson

    • Menus in Windows Forms
    Unit 4: Displaying and Editing Data by Using Data-Bound Controls

    This unit introduces the controls that can be used to display data from a data source. It shows how to use Visual Studio 2005 to create data sources and add data-bound controls to a form. It also demonstrates how to use the DataGridView control to display and update data retrieved by using a data source.

    Lessons

    • Binding Data to a Control
    • DataGridView Control
    Unit 5: Providing User Assistance and Enhancing Usability

    This unit introduces many of the controls and techniques that can be used to create an application that is flexible and intuitive and that provides timely feedback to the user. It shows how to add and configure the available user assistance controls to provide ToolTips, Help, and information about errors. It also describes the accessibility features of Windows Forms and explains how to implement globalization and localization in an application.

    Lessons

    • Providing User Assistance
    • Implementing Accessibility Features
    • Implementing Globalization and Localization
    Unit 6: Creating Consistent Applications by Using Dialog Boxes and Forms Inheritance

    This unit introduces the built-in dialog boxes that can be used to prompt users when they are performing common tasks and to provide users with a familiar interface. It explains how to add and configure dialog boxes that enable users to open and save files and to set font and color properties. This unit also explains how to create and use a custom dialog box. In addition, this unit explains the concept of forms inheritance and describes how to create a consistent interface for Windows Forms applications.

    Lessons

    • Dialog Boxes in a Windows Forms Application
    • Windows Forms Inheritance
    Unit 7: Printing Content and Creating Reports

    This unit provides an introduction to the components that can be used to preview and print reports from a Windows Forms application. This unit covers the predefined dialog boxes that simplify the processes involved, and it explains how to use these dialog boxes to retrieve print settings and page setup options from the user.

    In addition, this unit explains how to display a report in a Windows Forms application by using the CrystalReportViewer component

    Lessons

    • Printing in a Windows Forms Application
    • Reporting in a Windows Forms Application
    Unit 8: Performing Asynchronous Tasks by Using the BackgroundWorker Component

    This unit introduces the main concepts of asynchronous programming and then focuses on the BackgroundWorker component. It explains how to work with the methods and events of the BackgroundWorker component to add asynchronous functionality to a Windows Forms application.

    Lesson

    • Asynchronous Tasks in Windows Forms Applications
    Unit 9: Deploying Applications by Using ClickOnce

    This unit explains how to deploy a Windows Forms application by using ClickOnce. It covers the steps required to prepare, publish, install, and test an application. Finally, this unit explains how to update an application and how to use the automatic update feature of ClickOnce.

    Lessons

    • Windows Forms Application Deployment Options
    • ClickOnce Technology Overview
    Posted Jun 12 2007, 04:02 PM by Brett with no comments
    Filed under:
More Posts Next page »
Add to Technorati Favorites
Powered by Community Server (Commercial Edition), by Telligent Systems
Afrigator