Examples Of Databases
Hand in Hand – Database and Code Refractoring for Quality and Low cost Enterprise Software
Hand in Hand – Database and Code Refractoring for Quality and Low cost Enterprise Software
K.Ravi
Abstract
Any software project development is supported by a programming language code (Front End) and a Database (Back end).
Producing software is a very complex process that takes a considerable time to evolve. Poorly designed software systems are difficult to understand and maintain. Modifying code in one place could lead to unwanted repercussions elsewhere due to high coupling. Adding new features can cause further quality degradation to the code if proper design and architectural concerns were not implemented. Development in a large enterprise system with such attributes will, over time, lead to a myriad of concerns unless the system is periodically overhauled or refactored in some way.
Software maintenance can take up to 50% of the overall development costs of producing software. One of the main attributes to these high costs is poorly designed code, which makes it difficult for developers to understand the system even before considering implementing new code. In the context of software engineering process, Software Refactoring has a direct influence on reducing the cost of software maintenance through changing the internal structure of the code to increase the design which helps the present and future developers evolve and understand the system.
In this article we shall discuss mainly about database and code refractoring as these two are the major components of any software development
Key words: Software Refractoring, Database refractoring, Software maintenance
1.Database Refractoring
A database refactoring is a small change to a database schema which improves its design without changing, at a practical level, the semantics of the database. In other words, it is a Simple Database transformation which neither adds nor breaks anything. The process of database refactoring defines how to safely evolve a database schema in small steps. Database refactoring enables data professionals to work in an evolutionary manner, just as modern application developers do. It also provides a coherent strategy for organizations to dig their way out of the legacy database hole.
A database refactoring is a simple change to a database schema that improves its design while retaining both its behavioral and informational semantics. For the sake of this discussion a database schema includes both structural aspects such as table and view definitions as well as functional aspects such as stored procedures and triggers. An interesting thing to note is that a database refactoring is conceptually more difficult than a code refactoring; code refactorings only need to maintain behavioral semantics while database refactorings also must maintain informational semantics.
2. Why Database Refactoring?
There are two fundamental reasons why you want to adopt database refactoring:
- To repair existing legacy databases. Database refactoring enables you to safely evolve your Database Design in small steps, making it an important technique for improving the legacy assets within your organization. This is clearly much less risky than a “big bang” approach where you rewrite all of your applications and rework your database schema and release them all into production at once. Furthermore, it is much better than the “let’s try not to allow things to get any worse” strategy currently employed by the vast majority of data management groups which I’ve run into, a strategy which has no hope of success because all it takes is one development team to go around the data management group and do an imperfect database design.
The bottom line is that legacy databases aren’t going to fix themselves, and that from a technical point of view database refactoring is a safe, simple way to improve data, and database, quality over time. July 2006 survey into the current state of data management shows that 33% of organizations either are, or intend to take, an refactoring-based approach to addressing existing production data quality problems.
- To support evolutionary software development. Modern software development processes, including the Rational Unified Process (RUP), Extreme Programming (XP), Agile Unified Process (AUP), Scrum, and Dynamic System Development Method (DSDM), are all evolutionary in nature. Craig Larman [4] summarizes the research evidence, as well as the overwhelming support among the thought leaders within the IT community, in support of evolutionary approaches. Unfortunately, most data-oriented techniques are serial in nature, relying on specialists performing relatively narrow tasks, such as logical data modeling or physical data modeling. Therein lies the rub – the two groups need to work together, but both want to do so in different manners. I believe that data professionals need to adopt evolutionary techniques, such as database refactoring, which enable them to be relevant to modern development teams. Luckily these techniques exist, and they work quite well, it is now up to data professionals to choose to adopt them.
3.The lifecycle of a database refactoring.
4.The process of database refactoring.
Database refactoring as a three-step process:
1.Start in your development sandbox
2. Implement in your integration sandbox (es)
3.Install into production
Step 1: Start In Your Development Sandbox
Your development sandbox is the technical environment where your software, including both your application code and database schema, is developed and unit tested. The need to refactor your database schema is typically identified by an application developer who is trying to implement a new requirement or who is fixing a defect. For example, a developer may need to extend their application to accept Canadian mailing addresses in addition to American addresses. The main difference is that Canadian addresses have postal codes such as R2D 2C3 instead of zip codes such as 90210-1234. Unfortunately the ZipCode column of the Surface Address table is numeric and therefore will not currently support Canadian postal codes. The application developer describes the needed change to one of the Agile DBA(s) on their project and the database refactoring effort begins.
As depicted in Figure, the Agile DBA and application developer will typically work through some or all of the following steps to implement the refactoring:
•Verify that a database refactoring is required
•Choose the most appropriate database refactoring
•Deprecate the original schema
•Write unit tests
•Modify the database schema
•Migrate the source data
•Update external access programs
•Update your data migration script(s)
•Run your regression tests
•Announce the refactoring
•Version control your work
Fig. Database refactoring process
Step 2: Implement In Your Integration Sandbox
After several days have passed you will be ready to implement your database refactoring within your project integration sandbox. The reason why you need to wait to do so is to give your teammates time to refactor their own code to use the new schema.
Teams that have chosen to encapsulate access to their database via the use of a persistence framework will find it easier to react to database schema changes and therefore may discover they can tighten up the period between implementing a database refactoring within a development sandbox and in their project integration sandbox. This is due to the fact that the database schema is represented in meta data, therefore many database schema changes will only require updates to the meta data and not to the actual source code.
To deploy into each sandbox you will need to both build your application and run your Database Management scripts (tools such as Autopatch can help). The next step is to rerun your regression tests to ensure that your system still works – if not you will need to fix it in your development environment, redeploy, and retest. The goal in your project integration sandbox is to validate that the work of everyone on your team works together, whereas your goal in the Test/QA sandbox is to validate that your system works well with the other systems within your organization.
A critical part of deploying database refactorings into your Test/QA sandbox, I’m using the plural now because you typically introduce several database factors into this environment at once, is communication. Long before you change your database schema you need to communicate and negotiate the changes with the owners of all of the other applications that access your database. Your enterprise administrators will be involved in this negotiation, they may even facilitate the effort, to ensure that the overall needs of your organization are met. Luckily the process that you followed in your development sandbox has made this aspect of database refactoring easier:
• The Agile DBA only allowed database refactorings that can realistically be implemented – if another application team isn’t going to be able to rework their code to access the new schema then you can’t make the change.
• The documentation, even if it’s only a brief description of each change, that the Agile DBA wrote is important because it provides an overview of the changes that are about to be deployed.
• The new version physical data model (PDM), which was updated as database refactorings were implemented, serves as a focal point for the negotiations with other teams. Agile Modeling (AM) would consider the PDM to be a “contract model” that your team has with the other application teams, a model that they can count on to be accurate and that they can count on being actively involved in negotiating changes to it.
Step 3: Install Into Production
Installing into production is the hardest part of database refactoring, particularly in the complex situation of Figure . You generally won’t deploy database refactorings on their own, instead you will deploy them as part of the overall deployment of one or more systems. Deployment is easiest when you have one application and one database to update, and this situation does occur in practice, but realistically we need to consider the situation where you are deploying several systems and several data sources at once. Figure overviews the steps of deploying your refactorings into production.
Fig. Deploying database refactorings
5.A Simple Customer Database schema Example
The initial database schema. The Transition period. The final database schema
Figure depicts the best-case scenario for database refactoring – when it is only your application code that is coupled to your database schema. Figure depicts the worst-case scenario for database refactoring efforts where a wide variety of software systems are coupled to your database schema, a situation that is quite common with existing production databases.
Fig.Best case scenario
Fig.Worst Case Scenario
6.Database Refactoring Best Practices
- Refactor to ease additions to your schema.
- Ensure the test suite is in place.
- Take small steps.
- Program for people.
- Don’t publish data models prematurely.
- The need to document reflects a need to refactor.
- Test frequently.
7.Categories of database refactoring:
Structural: A change to the table structure of your database schema.
Data quality: A change which improves and/or ensures the consistency and usage of the values stored within the database.
Referential integrity: A change which ensures that a referenced row exists within another table and/or that ensures that a row which is no longer needed is removed appropriately.
Architectural: A change which improves the overall manner in which external programs interact with a database.
Method: A change which improves the quality of a stored procedure, stored function, or trigger.
Non-refactoring transformations: A change which changes the semantics of your database schema by adding new elements to it or by modifying existing elements.
Table of Database Refractoring Catogories
Category
Database Refactorings
Structural Refactorings
- Drop Column
- Drop Table
- Drop View
- Introduce Calculated Column
- Introduce Surrogate Key
- Merge Columns
- Merge Tables
- Move Column
- Rename Column
- Rename Table
- Rename View
- Replace LOB With Table
- Replace Column
- Replace One-to-Many With Associative Table
- Replace Surrogate Key with Natural Key
- Split Column
- Split Table
Data Quality Refactorings
- Add Lookup Table
- Apply Standard Codes
- Apply Standard Type
- Consolidate Key Strategy
- Drop Column Constraint
- Drop Default Value
- Drop Non-Nullable Constraint
- Introduce Column Constraint
- Introduce Common Format
- Introduce Default Value
- Make Column Non-Nullable
- Move Data
- Replace Type Code With Property Flags
Referential Integrity
Refactorings
- Add Foreign Key Constraint
- Add Trigger for Calculated Column
- Drop Foreign Key Constraint
- Introduce Cascading Delete
- Introduce Hard Delete
- Introduce Soft Delete
- Introduce Trigger for History
Architectural Refactorings
- Add CRUD Methods
- Add Mirror Table
- Add Read Method
- Encapsulate Table With View
- Introduce Calculation Method
- Introduce Index
- Introduce Read Only Table
- Migrate Method From Database
- Migrate Method to Database
- Replace Method(s) With View
- Replace View With Method(s)
- Use Official Data Source
Method Refactorings
- Add Parameter
- Consolidate Conditional Expression
- Decompose Conditional
- Extract Method
- Introduce Variable
- Parameterize Methods
- Remove Control Flag
- Remove Middleman
- Remove Parameter
- Rename Method
- Reorder Parameters
- Replace Literal With Table Lookup
- Replace Nested Expression With Guard Clauses
- Replace Parameter With Specific Methods
- Split Temporary Variable
- Substitute Algorithm
Non-Refactoring Transformations
- Insert Data
- Introduce New Column
- Introduce New Table
- Introduce View
- Update Data
8.Tools to Help
Doing this kind of thing requires a lot of repetitive tasks. The good news is that whenever you run into run into repetitive tasks in software development you are ideally placed to automate them. As a result we’ve developed a fair amount of often simple tools to help us.
One of the most valuable pieces of automation is a simple set of scripts for common database tasks.
- Bring a user up to date with the current master.
- Create a new user
- Copy a database schema, for example Sue finds a bug with her database, now Mike can copy Sue’s database and try to debug the application
- Move a database, for example from a Workstation to a different workstation, this is essentially Copy database and Delete database combined as one
- Drop a user
- Export a user so team members can make offine backups of the database that they are working with.
- Import a user, so if the team members have a backup copy of the database, they can import the backup and create a new schema.
- Export a baseline – make a backup copy of the master database. This is a specialized case of Export a User
- Create a difference report of any number of schemas, so that Mike can find out what is different structurally between his database and Sue’s.
- Diff a schema against the master, so that developers can compare their local copy against the master.
- List all the users
To conclude, Database refactoring is a database implementation technique, just like code refactoring is an application implementation technique. You refactor your database schema to ease additions to it. You often find that you have to add a new feature to a database, such as a new column or stored procedure, but the existing design is not the best one possible to easily support that new feature. You start by refactoring your database schema to make it easier to add the feature, and after the refactoring has been successfully applied, you then add the feature. The advantage of this approach is that you are slowly, but constantly, improving the quality of your database design. This process not only makes your database easier to understand and use, it also makes it easier to evolve over time; in other words, you improve your overall development productivity.
Experience is that data professionals can benefit from adopting modern evolutionary techniques similar to those of developers, and that database refactoring is one of several important skills that data professionals require. Evolutionary development has arguably become the norm within the IT community, and agile software development approaches extend evolutionary methods to become more effective. Data professionals take evolutionary and agile concepts and techniques seriously: they’re real, they work, and they’re here to stay.
9.Software (Code) Refractoring
Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation called a ‘refactoring’ does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it’s less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.
10.Refactor to Improve Code Design
Refactoring restructures your code into a more simplified or efficient form in a disciplined way. Refactoring software code improves its internal structure without changing external functionality for more efficient execution, faster download speed, and easier updates.
Refactoring is the art of reworking your code into a more simplified or efficient form in a disciplined way. Refactoring improves internal code structure without altering its external functionality by transforming functions and rethinking algorithms. Consequently, refactoring is an iterative process. By refactoring your JavaScript, Flash, and Java you can streamline its size, simplify your code, and speed up download and execution speed.
Martin Fowler, who wrote the book on refactoring, calls these changes “transformations.” Individual transformations may make small improvements, but taken as a whole transformations can make a significant improvement to your code. Refactorings include reducing scope, replacing complex instructions with simpler or built-in instructions, and combining multiple statements into one statement. Here’s a simple example that replaces an assignment with an initialization. So instead of this:
function foo() { var i; // … i = 5;}
Do this:
function foo() { var i = 5; // …}
11.The Need Refactoring
Continuous design allows one to add more flexibility into the design, by adding to an initially simple design as the need arises, instead of having a big upfront design. Thus the design will evolve as the code grows. There is a shift from building software towards growing it. The process of refactoring can be used to contribute to these evolving states of the code.
- Refactoring improves the design of software
Without refactoring the design of the program will decay. Poorly designed code usually takes more to do the same things, often because the does the same thing in different places
- Refactoring makes the code easier to understand
In most software development environments, somebody else will eventually have to read the code so it becomes easy for others to comprehend.
- Refactoring helps to find bugs
It helps in finding the Bugs present in the program.
- Refactoring helps to program faster
It helps us to do the coding/programming faster as we have better understanding of the situation.
Refactoring is the process of clarifying and simplifying the design of existing code, without changing its behavior. Un-refactored code tends to rot. Rot takes several forms: unhealthy dependencies between classes or packages, bad allocation of class responsibilities, duplicate code, and many other varieties of confusion and clutter. (Check out this list of such “design smells.”)
Rot is what makes code difficult to maintain or extend. Every time we change code without refactoring it, rot worsens and spreads. Code rot frustrates us, costs us time, and unduly shortens the lifespan of useful systems.
Refactoring code ruthlessly prevents rot, by keeping code easy to maintain and extend. This extensibility is the reason to refactor and the measure of its success. This is what enables XP teams to embrace arbitrary and drastic change. Note that the XP practice of Test-driven Development (TDD) is essential to refactoring. The exhaustive tests produced by TDD are what make it safe and orderly to make changes of any kind. This is why Adaption always teaches TDD and refactoring together.
12.Code Hygiene
What does “refactor ruthlessly” mean? It means striving as a matter of routine to keep the code’s design simple and crystal clear. It means knowing the design principles and patterns that are vital to keeping code extensible, and knowing when to “refactor toward” them. It means refactoring both production code and test code frequently during the day, eliminating all forms of the “code smells” that are precursors to true rot.
Mainly it means never going home at the end of the day with “code debts” that need paying tomorrow (smelly sections that need cleaning up). This level of code hygiene may at first seem like a lot of extra work, but it pays you such dividends so soon and so regularly that you soon become ddicted to it — rather like TDD.
13.Specific “Refactorings”
Refactorings are the opposite of fiddling endlessly with code; they are precise and finite. Martin Fowler’s definitive book on the subject describes 72 specific “refactorings” by name (e.g., “Extract Method,” which extracts a block of code from one method, and creates a new method for it). Each refactoring converts a section of code (a block, a method, a class) from one of 22 well-understood “smelly” states to a more optimal state. It takes awhile to learn to recognize refactoring opportunities, and to implement refactorings properly. This is a practice at the heart of high software craft.
14.The Flow of Refactoring
In a TDD context, refactoring has the same flow as any other code change. You have your automated tests. You begin the refactoring by making the smallest discrete change you can that will compile, run, and function. Wherever possible, you make such changes by adding to the existing code, in parallel with it. You run the tests. You then make the next small discrete change, and run the tests again. When the refactoring is in place and the tests all run clean, you go back and remove the old smelly parallel code. Once the tests run clean after that, you are done. Badabing, badaboom: cleaner code, with no new bugs.
15.Refactoring Automation in IDEs
Fortunately, more and more Integrated Development Environments (IDEs) are building in automated refactoring support. For example, Adaption’s favorite IDE for Java is eclipse, which includes more auto-refactorings all the time. Another favorite is IntelliJ IDEA.
To refactor code in eclipse or IDEA, you select the code you want to refactor, pull down the specific refactoring you need from a menu, and the IDE does the rest of the hard work. You are prompted appropriately for new names for things that need naming, and for similar input. You can then immediately rerun your tests to make sure that the change didn’t break anything. If anything was broken, you can easily undo the refactoring and investigate.
16.Refactoring activities
The refactoring process consists of a number of different activities, each of which can be automated to a certain extent:
(1) Identify where the software should be refactored;
(2) Determine which refactorings should be applied to the identified places;
(3) Guarantee that the applied refactoring preserves behavior;
(4) Apply the refactoring;
(5) Assess the effect of refactoring on software quality characteristics;
(6) Maintain consistency between refactored program code and other software artifacts (or vice versa).
The steps taken when applying the refactoring should be small enough to oversee the consequences they have and reproduceable to allow others to understand them. Generalized refactoring steps in a way, are more a rule that can be applied to any structure.
Refactoring as proposed by Fowler not only covers the mechanics of restructuring, but also addresses the following issues:
• Refactoring emphasizes that, in absence of more formal guarantees, testing should be used to ensure that each restructuring is behavior preserving. A rich test suite should be built, which must be run before and after each test is applied.
• Refactorings are described in a catalog, using a template reminiscent of design patterns.
• Refactorings are applied in small steps, one by one, running the test suite after every step to make it into commercial development tools.
17.Refactoring techniques
A Few Refactoring Techniques
- Add Parameter
- Rename Method
- Remove Parameter
- Move Field
- Extract method
- Extract class
- Extract Interface
- Hide delegate
- Pull up Method
- Push down Method
- Push down Field
- Inline class
- Inline Method
- Encapsulate field
- Collapse hierarchy etc
17.1Extract Method
A fragment of code that can be grouped together, turn it into a method with a name that explains the purpose of the method.
void printFormatted(string text)
{
System.out.println (“Refractoring the Code”);
“System.out.println (“Author: Venkatesh”);
printRest(text);
}
void printFormatted(string text) {
printHeader();
printRest(text);
}
printHeader()
{
System.out.println(“Refractoring the Code”);
System.out.println(“Author: Venkatesh”) ;}
18.Refactoring tool support
18.1Language Support
Support for restructuring has been provided in a variety of different programming languages and language paradigms: imperative or procedural languages (FORTRAN, Cobol, C); functional languages (Scheme, Lisp, Haskel); logic languages (e.g., Prolog); class-based object-oriented languages (Smalltalk, Java, C++); prototype-based object oriented languages (e.g., Self ); aspect-oriented languages (e.g., AspectJ).
18.2Tool Support
Refactoring tools are difficult to construct. They need to be correct but also highly usable, where “usable” in this context includes interactive, fast, user-friendly, integrated, and exploratory. After some experience on constructing refactoring tools is gained, the task of expanding to new programming languages may hopefully become easier.
Eclipse was among the first IDEs to help bring refactoring to the mainstream developer. Eclipse version 1.0 included several highly useful Java refactorings, which are nowadays staple tools in most Java developers’ toolbox.
These included Rename, Move, and Extract Method. Eclipse 2.0 added a lot of statement-level refactorings such as Extract and Inline Local Variable, Change Method Signature, and Encapsulate Field. Some refactorings, such as Rename, offer great leverage because of the potential scale of the changes they perform automatically. Others, like Extract Method, are more local in scope, but relieve the developer from performing the analysis required to ensure that program behavior is unaffected. In both cases, the developer benefits from reduction of a complex and numerous changes to a single operation. This helps to maintain his focus on the big picture. Moreover, the ability to roll back the changes with a single gesture enables exploration of structural possibilities more easily, and without fear of irreparable damage to the code base.
19.Eclipse & Net beans – Java refactoring
Refractoring using Net Beans
Finally Software Refactoring is an important area of research that promises substantial benefits to software maintenance. Refactoring is a process that improves the quality and allows developers to repair code that is becoming hard to maintain, without throwing away the existing source code and starting again. We can return with a well structured and well designed code after proper application of refactoring techniques. Refactoring naturally fits in an agile software development process. It forms even one of the cornerstones of the eXtreme Programming process; together with unit testing. The research in software engineering continues to be very active.
20.Conclusion:
Up to 75% of the costs associated with the development of software systems occur post-deployment during maintenance and evolution. Software refactoring is a process that can significantly reduce the costs associated with software evolution. Refactoring is defined as internal modification of source code to improve system quality, without change to observable behaviour. Tool support for software refactoring attempts to further reduce evolution costs by automating manual, error-prone and tedious tasks. Although the process of refactoring is well-defined, tools supporting refactoring do not support the full process. Existing tools suffer from issues associated with the level of automation, the stages of the refactoring process supported or automated, the subset of refactorings that can be applied, and complexity of the supported refactorings.
References
[1] Fowler, M. (1999). Refactoring: Improving the Design of Existing Code.
Menlo Park, California: Addison Wesley Longman, Inc.
[2] Ambler, S.W. (2003). Agile Database Techniques: Effective Strategies for
the Agile Software Developer. New York: John Wiley & Sons. www.ambysoft.com/books/agileDatabaseTechniques.html
[3] Ambler, S.W. and Sadalage, P.J. (2006). Refactoring Databases:
Evolutionary Database Design. Boston: Addison Wesley. www.ambysoft.com/books/refactoringDatabases.html
[4] Larman, C. (2004). Agile and Iterative Development: A Manager’s Guide.
Boston: Addison-Wesley.
[5] Astels D. (2003). Test Driven Development: A Practical Guide. Upper
Saddle River, NJ: Prentice Hall.
[6] Beck, K. (2003). Test Driven Development: By Example. Boston, MA:
Addison Wesley.
[7] Ambler, S.W. (2004). Introduction to Test Driven Development (TDD).
www.agiledata.org/essays/tdd.html
[8] Ambler, S.W. (2004). The Agile Data Home Page. www.agiledata.org.
[9] Ambler, S.W. (2002). Agile Modeling: Best Practices for the Unified
Process and Extreme Programming. New York: John Wiley & Sons. www.ambysoft.com/books/agileModeling.html
[10] Ambler, S.W. Agile Model Driven Development (AMDD).
www.agilemodeling.com/essays/amdd.htm
[11] Java Refactorings in Eclipse-http://www.eclipse.org
[12] Martin Fowler, „Refactoring Home Page”-http://www.refactoring.com
[13] Fowler, martin: A list of refactoring tools for several languages,-
http://www.refactoring.com/tools.html
[14] Discussion site on code smells -http://c2.com/cgi/wiki?CodeSmell
[1] V V N Kumar,email:naren6568@rediffmail.com,K.Rav,kolipakaravi@yahoo.co.in Faculty Department of Informatics,Alluri Institute of Management Sciences,Warangal,A.P.-506001(India)
About the Author
K.Ravi
Assist.professor
Dept. of Informatics
Alluri Institute of Management Sciences
Hunter Road, Warangal-506002
Converting Database Searches to RSS Feeds: Four Examples from Licensed and Public Databases
|
|
Inside Relational Databases With Examples in Access $66.86 This book is in Used condition |
|
|
Examples $46.95 This book is in Used condition |
|
|
Databases Illuminated $76.95 Databases Illuminated, Second Edition integrates database theory with a practical approach to database design and implementation. The text is specifically designed for the modern database student, who will be expected to know both theory and applied design and implementation as professionals in the field. This Second Edition has been revised and updated to incorporate information about the new releases of Access 2010, Oracle 11g, and Intersystems Cache. It includes material on the most recent topics such as, Web access, JDBC, web programming, XML, data mining, and other emerging database technologies and applications. Instructor resources include Microsoft PowerPoint lecture slides, solutions to all the exercises and projects in the text, test bank, and a complete instructor’s manual that includes objectives and teaching hints. Student resources include an open access companion website featuring: -downloadable code -projects with step-by-step guidance that ensure students fully understand each step before moving on to the next. -hands-on lab exercises that allow students to apply the concepts learned from the text -additional information not included in the text to allow for further study The integrated, modern approach to databases, combined with strong pedagogical features, accessible writing, and a full package of student and instructor’s resources, makes Databases Illuminated, Second Edition the perfect textbook for courses in this exciting field. New and Key Features of the updated Second Edition: -Covers the new features of the current versions of popular database management systems, including Oracle 11, Access 2010, and InterSystems Cache. -Incorporates the new curriculum recommendations in ACM Computer Science Curriculum 2008 and ACM/AIS IS2010 Curriculum Guidelines for IS2010.2, Data and Information Management, including more attention to security, concurrency, and net-centric computing. The chapter on computer ethics has been updated to take into account new regulations and practices. -Contains more material on recent and relevant topics, such as Web access, JDBC, web programming, XML, data warehousing, data mining, and other emerging database technologies and applications. -Includes the extensive object-relational features of the current release of Oracle, with downloadable code for students to implement; Object-oriented databases are implemented using InterSystems Cache, with downloadable code included on the website. |
|
|
Examples of Isomerism $59.99 Edward L. Youmans Examples of Isomerism – Wall Decal |
|
|
Spotlight on Databases $1.9 No Synopsis Available |
|
|
.NET 3.5 Wrox Box: Professional ASP.NET 3.5, Professional C# 2008, Professional LINQ, .NET Domain-Driven Design with C# $89.17 Put AJAX, LINQ, and a new CSS designer into action Here’s coverage of all the key technologies retained from ASP.NET 2.0 plus all the new 3.5 features. You’ll learn the language from this book and refer to it many times over. You’ll find:How to implement ASP.NET 3.5 AJAX and the ASP.NET AJAX ToolkitLINQ examples side-by-side with SQLCoverage of Scott Hanselman’s famous productivity tool picks for ASP.NETLanguage examples in C# and VBThe ultimate guide to C# 2008 and its environmentUpdated for .NET 3.5 and Visual Studio® 2008, this book examines the architecture and methodology of .NET, provides an understanding of the foundation of C#, and shows how C# must be considered in parallel with the .NET Framework. Coverage includes:LINQ, LINQ to SQL, LINQ to XML, and ADO.NET entitiesWindows Communication FoundationWindows Workflow FoundationWindows Presentation FoundationQuery XML, SQL databases, and more with LINQExplore the technology and discover how LINQ can dramatically improve your applications. Discover the language-specific features that support LINQ and see how to program with LINQ to XML with both C# and Visual Basic®. You’ll learn:The syntax to use when writing LINQ queries All about LINQ to SQL queries and conceptsWays to work with the DataContext class and entity objectsBuild a real-world app using domain-driven designBased on a real application for an existing company, the project you’ll build focuses on the domain object model and its supporting framework. You’ll identify the problem, decide on the best solutions, and execute that design. Learn:When, why, and how to use domain-driven designHow to design and build the initial domain modelWays to handle proposal requests, submit transmittals, and change orders |
|
|
20% Chance of Rain $39.95 There are plenty of books on specialized risk topics but few that deal with the broad diversity and daily applicability of this subject. Risk applications require a robust knowledge of many attributes of this seemingly simple subject. This book teaches the reader through examples and case studies the fundamental (and subtle) aspects of risk – regardless of the specific situation. The text allows the reader to understand the concept of risk analysis while not getting too involved in the mathematics; in this method the reader can apply these techniques across a wide range of situations.The second edition includes new examples from NASA and several other industries as well as new case studies from legal databases. The many real-life discussion topics enable the reader to form an understanding of the concepts of risk and risk management and apply them to day-to-day issues – |
|
|
4th Dimension: A Complete Guide to Database Development $16.95 Used – Suitable for beginners, this clear, concise, guidebook covers basic and advanced features of 4th Dimension including how to build and use databases. Step-by-step instructions offer plenty of examples, hints, and strategies. |
|
|
4th Dimension: A Complete Guide to Database Development $19.71 Used – Suitable for beginners, this clear, concise, guidebook covers basic and advanced features of 4th Dimension including how to build and use databases. Step-by-step instructions offer plenty of examples, hints, and strategies. |
|
|
A Cell Biologist’s Guide to Modeling and Bioinformatics $117.34 New – A step-by-step guide to using computational tools to solve problems in cell biologyCombining expert discussion with examples that can be reproduced by the reader, “A Cell Biologist’s Guide to Modeling and Bioinformatics” introduces an array of informatics tools that are available for analyzing biological data and modeling cellular processes. You learn to fully leverage public databases and create your own computational models. All that you need is a working knowledge of algebra and cellula |
|
|
A Cell Biologist’s Guide to Modeling and Bioinformatics $180.55 New – A step-by-step guide to using computational tools to solve problems in cell biologyCombining expert discussion with examples that can be reproduced by the reader, “A Cell Biologist’s Guide to Modeling and Bioinformatics” introduces an array of informatics tools that are available for analyzing biological data and modeling cellular processes. You learn to fully leverage public databases and create your own computational models. All that you need is a working knowledge of algebra and cellula |
|
|
A Cell Biologist’s Guide to Modeling and Bioinformatics $105.06 New – A step-by-step guide to using computational tools to solve problems in cell biologyCombining expert discussion with examples that can be reproduced by the reader, “A Cell Biologist’s Guide to Modeling and Bioinformatics” introduces an array of informatics tools that are available for analyzing biological data and modeling cellular processes. You learn to fully leverage public databases and create your own computational models. All that you need is a working knowledge of algebra and cellula |
|
|
A Cell Biologist’s Guide to Modeling and Bioinformatics $65.28 A Cell Biologist’s Guide to Modeling and Bioinformatics introduces an array of informatics tools that are available for analyzing biological data and modeling cellular processes. This book combines expert discussion with examples that can be reproduced by the reader, who will quickly learn to fully leverage public databases and create her or his own computational models. Assuming only a working knowledge of algebra and cellular biology, the author provides all the other tools that the reader will need to understand the necessary statistical and mathematical methods. |
|
|
A Cell Biologist’s Guide to Modeling and Bioinformatics $159.53 New – A step-by-step guide to using computational tools to solve problems in cell biologyCombining expert discussion with examples that can be reproduced by the reader, “A Cell Biologist’s Guide to Modeling and Bioinformatics” introduces an array of informatics tools that are available for analyzing biological data and modeling cellular processes. You learn to fully leverage public databases and create your own computational models. All that you need is a working knowledge of algebra and cellula |
|
|
A Cell Biologist’s Guide to Modeling and Bioinformatics $180.55 New – A step-by-step guide to using computational tools to solve problems in cell biologyCombining expert discussion with examples that can be reproduced by the reader, “A Cell Biologist’s Guide to Modeling and Bioinformatics” introduces an array of informatics tools that are available for analyzing biological data and modeling cellular processes. You learn to fully leverage public databases and create your own computational models. All that you need is a working knowledge of algebra and cellula |