If you landed on this page from a search engine, we would recommend starting with the first chapter
Let's define what is that we are trying to integrate continuously. At the first glance, it might seem obvious that we are talking about just the one thing - the database, and that is our product of integration. 
Do we really talk about one thing?
When we say - "database" - here is what people might think:
-
DBA would think of physical servers with database software instances (like Oracle or SQL Server) installed on a few servers, a database created with files located on physical and logical drives, and populated with data;
-
Developer who works with database centered application might think of a few tables that exist somewhere in a database this application have access to;
-
Database designer might think of relationship, integrity, access control, particular database objects that achieve the required functionality;
-
User would think simply of data. Data loaded from raw files, collected from sensors, manually entered, bought or acquired in any other way. User needs data.
The magical "database" term removes obstacles and allows all stakeholders in their different roles work together, and at the same time it carries very high level of ambiguity.
Let's try to remove ambiguity, set expectations and to focus on actual CI implementation for a particular database product.
Please welcome the “DNA and The Creature” example:
|
DNA |
|
The Creature |
|
On one side there are developers and designers who create databases, write database code, create packages and procedures |
The Terminology Wall |
On the other side, there are Users who use data in a database and DBAs who support that database |
Let say, for example, we have designed a database that describe a creature, the "The Creature" database. Two tables is all we need:
CREATE DATABASE TheCreature
GO
CREATE TABLE CreatureAttributes(
AttributeID int,
Name nvarchar(50),
Value nvarchar(50)
)
GO
CREATE TABLE SignificantEvents(
EventID int,
EventDate datetime,
EventDescription nchar(10)
)
GO
Done - we got a product. So… Coding is done; testing is done, we got approval from the client; we saved our code in source control system as one small file called A_Creature_DNA.sql
Then, this product (the SQL file) was distributed to many divisions of the company. Many departments installed this product internally on their production servers and started using their own “The Creature” databases.
Let say one office accumulated following data:
CreatureAttributes table
|
AttributeID |
Name |
Value |
|
1 |
Class |
Mammal |
|
2 |
Family |
Rabbit |
|
3 |
Name |
Bunny |
|
4 |
Diet |
Herbivore |
|
5 |
Lifespan Limit |
12 years |
|
6 |
Birthday |
2012-01-01 |
SignificantEvents table
|
EventID
|
EventDate |
EventDescription |
|
1 |
2014-01-01 4:00 PM
|
New creature is born of class Mammal |
|
2 |
2014-01-01 4:01 PM |
New creature chooses to be a Rabbit |
|
3 |
2014-01-03 1:00 AM |
Creature tried to eat grass - and it likes it
|
|
4 |
2014-01-03 2:00 PM |
We named it Bunny |
|
5 |
2015-02-03 7:00 PM
|
Bunny ran away from Fox. Very scary... |
|
6 |
2016-04-04 8:00 AM |
Bunny met Dolly, they are friends now |
|
7 |
2019-05-08 9:00 PM |
Bunny got to a hospital |
|
8 |
2019-05-09 5:00 AM |
Bunny feels better and going home |
|
9 |
2020-08-23 9:00 AM |
Bunny goes to school |
There also might be other department, who grew their rabbits or lions, or horses, or other unknown chimeras.
From a developer Joe standpoint, who invented “The Creature” database, the final database product is the SQL code for those two tables.
From user Jill standpoint, who uses this product daily, the “The Creature” database is in the actual database installed on the server and populated with real data.
Both Joe and Jill have different needs from the database. Both use a “database” term in their way. In the end, they are working with two different database products - the database code and the database that this code has created.