فصل ۱۱ — تبدیل‌ها

تبدیل‌ها (Transformations) تغییراتی هستند که با افزودن قابلیت‌های جدید، معناشناسی طرحوارهٔ پایگاه داده را تغییر می‌دهند. تبدیل‌های توصیف‌شده در این فصل عبارت‌اند از:

Insert Data
Introduce New Column
Introduce New Table
Introduce View
Update Data

Insert Data — درج داده

درج داده در جدول موجود.

انگیزه (Motivation)

معمولاً باید Insert Data را در نتیجهٔ تغییرات ساختاری در طراحی جدول اعمال کنید. ممکن است به‌دلایل زیر نیاز به Insert Data داشته باشید:

بازسازمان‌دهی جدول. هنگام استفاده از بازآرایی‌های Rename Table (صفحهٔ ۱۱۳)، Merge Tables (صفحهٔ ۹۶)، Split Table (صفحهٔ ۱۴۵) یا Drop Table (صفحهٔ ۷۷)، ممکن است مجبور شوید از Insert Data برای بازسازمان‌دهی داده در جداول موجود استفاده کنید.
فراهم کردن دادهٔ مرجع ثابت. همهٔ برنامه‌ها به دادهٔ مرجع ثابت نیاز دارند — برای مثال جداولی که ایالت‌ها/استان‌ها (مثلاً Illinois و Ontario) را که در آن‌ها فعالیت می‌کنید فهرست می‌کنند، فهرست انواع آدرس (مثلاً منزل، محل کار، تعطیلات) و فهرست انواع حساب (مثلاً جاری، پس‌انداز و سرمایه‌گذاری). اگر برنامهٔ شما صفحهٔ ویرایش مدیریتی برای نگه‌داری این فهرست‌ها ندارد، باید این داده را به‌صورت دستی درج کنید.
ایجاد دادهٔ آزمون. در طول توسعه، به مقادیر دادهٔ شناخته‌شده‌ای در پایگاه(های) دادهٔ توسعه نیاز دارید تا تلاش‌های آزمون را پشتیبانی کنید.

معاوضه‌های بالقوه (Potential Tradeoffs)

درج دادهٔ جدید در جداول می‌تواند پیچیده باشد، به‌ویژه وقتی دادهٔ مرجعی را درج می‌کنید که از یک یا چند جدول دیگر به آن ارجاع داده می‌شود. برای مثال، فرض کنید جدول Address به داده در جدول State ارجاع می‌دهد و شما دادهٔ جدیدی در State درج می‌کنید. داده‌ای که در State درج می‌کنید باید مقادیر معتبری داشته باشد که در Address ظاهر خواهند شد.

مکانیک به‌روزرسانی طرحواره (Schema Update Mechanics)

برای به‌روزرسانی طرحوارهٔ پایگاه داده باید موارد زیر را انجام دهید:

دادهٔ قابل درج را شناسایی کنید. این شامل شناسایی هر وابستگی است. اگر بخشی از انتقال داده از جدول دیگر است، آیا ردیف منبع باید حذف شود؟ آیا دادهٔ درج‌شده جدید است و اگر چنین است، آیا مقادیر توسط ذی‌نفع(ان) پروژه پذیرفته شده‌اند؟
مقصد داده را شناسایی کنید. داده در کدام جدول درج می‌شود؟
منبع داده را شناسایی کنید. آیا داده از جدول دیگری می‌آید یا درج دستی است (مثلاً اسکریپتی برای ایجاد داده می‌نویسید)؟
نیازهای تبدیل را شناسایی کنید. آیا دادهٔ منبع قبل از درج در جدول هدف باید تبدیل شود؟ برای مثال، ممکن است فهرستی از اندازه‌گیری‌های متریک داشته باشید که قبل از درج در جدول مرجع باید به مقادیر امپریال تبدیل شوند.

مکانیک مهاجرت داده (Data-Migration Mechanics)

وقتی مقادیر کمی داده باید درج شود، احتمالاً یک اسکریپت SQL ساده که دادهٔ منبع را در محل هدف درج می‌کند کافی است. برای مقادیر زیاد داده، باید رویکرد پیچیده‌تری اتخاذ کنید، مانند استفاده از ابزارهای پایگاه داده مانند SQLLDR اوراکل یا bulk loader (به‌خاطر زمانی که درج داده طول می‌کشد).

شکل ۱۱.۱ نشان می‌دهد چگونه رکورد جدیدی در جدول AccountType که حساب‌های کارگزاری را نشان می‌دهد درج می‌کنیم. این AccountType قابلیت جدیدی را پشتیبانی می‌کند که ابتدا باید آزمایش شود و سپس به تولید منتقل گردد. کد زیر DML درج داده در جدول AccountType را نشان می‌دهد:

شکل ۱۱.۱. درج AccountType جدید.

sql

INSERT INTO AccountType
(AccountTypeId,Name,EffectiveDate)
VALUES
(6,'Brokerage','Feb 1 2007');

مکانیک به‌روزرسانی برنامه‌های دسترسی (Access Program Update Mechanics)

وقتی Insert Data در نتیجهٔ بازآرایی دیگری در پایگاه داده اعمال می‌شود، برنامه‌ها باید برای انعکاس آن بازآرایی به‌روز شده باشند. با این حال، وقتی Insert Data برای پشتیبانی از افزودن داده در طرحوارهٔ موجود اعمال می‌شود، ممکن است کد برنامهٔ بیرونی نیاز به تغییر داشته باشد.

باید بندهای WHERE را به‌روز کنید. برای مثال، در شکل ۱۱.۱، Brokerage را در جدول AccountType درج کردیم. ممکن است لازم باشد عبارت‌های SELECT را به‌روز کنید تا وقتی فقط می‌خواهید با حساب‌های بانکی استاندارد کار کنید (همه به‌جز کارگزاری)، این مقدار خوانده نشود، همان‌طور که در کد زیر می‌بینید. همچنین می‌توانید از Introduce View (صفحهٔ ۳۰۶) برای ایجاد نمای خاصی که برنامه از آن استفاده می‌کند و این زیرمجموعه از داده را برمی‌گرداند بهره ببرید:

java

// Before code
stmt.prepare(
  "SELECT * FROM AccountType " +
    "WHERE AccountTypeId NOT IN (?,?)");
stmt.setLong(1,PRIVATEACCOUNT.getId);
stmt.setLong(2,MONEYMARKETACCOUNT.getId);
stmt.execute();
ResultSet standardAccountTypes = stmt.executeQuery();

//After code
stmt.prepare(
  "SELECT * FROM AccountType " +
    "WHERE AccountTypeId NOT IN (?,?,?)");
stmt.setLong(1,PRIVATEACCOUNT.getId);
stmt.setLong(2,MONEYMARKETACCOUNT.getId);
stmt.setLong(3,BROKERAGE.getId);
stmt.execute();
ResultSet standardAccountTypes = stmt.executeQuery();

به‌طور مشابه، باید کد منبعی را که مقادیر ویژگی‌های داده را اعتبارسنجی می‌کند به‌روز کنید. برای مثال، ممکن است کدی داشته باشید که در منطق برنامه حساب‌های ممتاز را از نوع Private یا Money Market تعریف می‌کند. اکنون باید Brokerage را به این فهرست اضافه کنید، همان‌طور که در کد زیر می‌بینید:

java

//Before code
public enum PremiumAccountType {
  PRIVATEACCOUNT(new Long(3)),
  MONEYMARKET(new Long(4));

private Long id;
public Long getId() {
  return id;
}

PremiumAccountType(Long value) {
  this.id = value;
}

public static Boolean
  isPremiumAccountType(Long idToFind) {
    for (PremiumAccountType premiumAccountType :
           PremiumAccountType.values()) {
      if (premiumAccountType.id.equals(idToFind))
         return Boolean.TRUE;
       }
         Return Boolean.FALSE
}

//After code
public enum PremiumAccountType {
  PRIVATEACCOUNT(new Long(3)),
  MONEYMARKET(new Long(4)),
  BROKERAGE(new Long(6));

private Long id;
public Long getId() {
  return id;
}

PremiumAccountType(Long value) {
  this.id = value;
}
public static Boolean
  isPremiumAccountType(Long idToFind) {
    for (PremiumAccountType premiumAccountType :
          PremiumAccountType.values()) {
       if (premiumAccountType.id.equals(idToFind))
          return Boolean.TRUE;
        }
         Return Boolean.FALSE
}

Introduce New Column — معرفی ستون جدید

معرفی ستون جدید در جدول موجود.

انگیزه (Motivation)

چند دلیل وجود دارد که ممکن است بخواهید تبدیل Introduce New Column را اعمال کنید:

برای پایدارسازی ویژگی جدید. نیازمندی جدید ممکن است افزودن ستون جدید در پایگاه داده را ضروری کند.
گام میانی یک بازآرایی. بسیاری از بازآرایی‌های پایگاه داده، مانند Move Column (صفحهٔ ۱۰۳) و Rename Column (صفحهٔ ۱۰۹)، گامی دارند که در آن ستون جدیدی در جدول موجود معرفی می‌کنید.

معاوضه‌های بالقوه (Potential Tradeoffs)

باید اطمینان حاصل کنید ستون در جای دیگری وجود ندارد؛ در غیر این صورت در معرض افزایش مشکلات یکپارچگی ارجاعی به‌خاطر افزایش افزونگی داده هستید.

مکانیک به‌روزرسانی طرحواره (Schema Update Mechanics)

همان‌طور که در شکل ۱۱.۲ نشان داده شده، برای به‌روزرسانی طرحوارهٔ پایگاه داده باید CountryCode را از طریق بند ADD دستور SQL ALTER TABLE معرفی کنید. ستون State.CountryCode ارجاع کلید خارجی به جدول Country است (نشان داده نشده) و به برنامه(های) ما امکان می‌دهد ایالت‌ها را بر اساس کشور ردیابی کند. کد زیر DDL معرفی ستون State.CountryCode را نشان می‌دهد. برای ایجاد محدودیت ارجاعی، بازآرایی Add Foreign Key Constraint (صفحهٔ ۲۰۴) را اعمال کنید:

شکل ۱۱.۲. معرفی ستون State.CountryCode.

sql

ALTER TABLE State ADD Country Code VARCHAR2(3) NULL;

مکانیک مهاجرت داده (Data-Migration Mechanics)

اگرچه به‌معنای دقیق مهاجرت داده نیست، چالش اصلی قابل‌توجه این تبدیل پر کردن ستون با مقادیر داده پس از افزودن آن به جدول است. باید موارد زیر را انجام دهید:

با ذی‌نفعان پروژه برای شناسایی مقادیر مناسب کار کنید.
یا مقادیر جدید را به‌صورت دستی در ستون وارد کنید یا اسکریپتی بنویسید که ستون را به‌طور خودکار پر کند (یا ترکیبی از دو راهبرد).
در صورت مناسب بودن، بازآرایی‌های Introduce Default Value (صفحهٔ ۱۸۶)، Drop Non-Nullable (صفحهٔ ۱۷۷) یا Make Column Non-Nullable (صفحهٔ ۱۸۹) را برای این ستون جدید در نظر بگیرید.

کد زیر DML پر کردن State.CountryCode با مقدار اولیهٔ 'USA' را نشان می‌دهد:

sql

UPDATE State SET CountryCode = 'USA'
  WHERE CountryCode IS NULL;

مکانیک به‌روزرسانی برنامه‌های دسترسی (Access Program Update Mechanics)

مکانیک به‌روزرسانی ساده است چون تنها کاری که باید انجام دهید استفاده از ستون جدید در برنامه(های) خود برای کار با آن ستون است. در کد زیر، نمونه‌ای از تأثیر بر متادیتای نگاشت ORM هibernate را نشان می‌دهیم:

xml

//Before mapping
<hibernate-mapping>
<class name="State" table="STATE">
  <id name="id" column="StateCode"></id>
  <property name="name"/>
</class>
</hibernate-mapping>
//After mapping
<hibernate-mapping>
<class name="State" table="STATE">
  <id name="id" column="StateCode"></id>
  <property name="name"/>
  <many-to-one name="country"
                class="Country"
                column="COUNTRYCODE"/>
</class>
</hibernate-mapping>

Introduce New Table — معرفی جدول جدید

معرفی جدول جدید در پایگاه دادهٔ موجود.

انگیزه (Motivation)

چند دلیل وجود دارد که ممکن است بخواهید تبدیل Introduce New Table را اعمال کنید:

برای پایدارسازی ویژگی جدید. نیازمندی جدید ممکن است افزودن جدول جدید در پایگاه داده را ضروری کند.
به‌عنوان گام میانی یک بازآرایی. بسیاری از بازآرایی‌های پایگاه داده، مانند Split Table (صفحهٔ ۱۴۵) و Rename Table (صفحهٔ ۱۱۳)، گامی دارند که در آن جدول جدیدی به‌جای جدول موجود معرفی می‌کنید.
برای معرفی منبع دادهٔ رسمی جدید. بسیار رایج است که اطلاعات مشابه در چند جدول ذخیره شده باشد. برای مثال، ممکن است چند منبع اطلاعات مشتری وجود داشته باشد که اغلب با یکدیگر ناهمگام و گاه حتی متناقض‌اند. در این سناریو باید از Use Official Data Source (صفحهٔ ۲۷۱) استفاده کنید و سپس به‌مرور Drop Table (صفحهٔ ۷۷) را روی جداول منبع اصلی اعمال کنید.
نیاز به پشتیبان‌گیری از داده. هنگام پیاده‌سازی برخی بازآرایی‌ها، مانند Drop Table (صفحهٔ ۷۷) یا Merge Tables (صفحهٔ ۹۶)، ممکن است لازم باشد جدولی برای نگه‌داری دادهٔ جدول برای کاربردهای میانی یا اهداف پشتیبان‌گیری ایجاد کنید.

معاوضه‌های بالقوه (Potential Tradeoffs)

معاوضهٔ اصلی این است که باید اطمینان حاصل کنید جدولی که می‌خواهید معرفی کنید در جای دیگری از قبل وجود ندارد. اغلب جدول دقیقی که نیاز دارید وجود ندارد، اما چیزی نزدیک وجود دارد — ممکن است کشف کنید بازآرایی آن جدول موجود آسان‌تر از افزودن جدول جدید حاوی اطلاعات افزونه است.

مکانیک به‌روزرسانی طرحواره (Schema Update Mechanics)

همان‌طور که در شکل ۱۱.۳ نشان داده شده، برای به‌روزرسانی طرحوارهٔ پایگاه داده باید CustomerIdentification را از طریق دستور SQL CREATE TABLE معرفی کنید. کد زیر DDL معرفی جدول CustomerIdentification را نشان می‌دهد. ستون CustomerIdentification.CustomerID ارجاع کلید خارجی به جدول Customer است (نشان داده نشده) و به برنامه(های) ما امکان می‌دهد راه‌های مختلف شناسایی مشتریان فردی را ردیابی کند:

شکل ۱۱.۳. معرفی جدول CustomerIdentification.

sql

CREATE TABLE CustomerIdentification(
  CustomerID NUMBER NOT NULL,
  Photo       BLOB,
  PassportID NUMBER,
  CONSTRAINT PK_CustomerIdentification
     PRIMARY KEY (CustomerID)
  );

مکانیک مهاجرت داده (Data-Migration Mechanics)

اگرچه به‌معنای دقیق مهاجرت داده نیست، چالش اصلی قابل‌توجه این تبدیل پر کردن جدول با مقادیر داده پس از افزودن آن به پایگاه داده است. باید موارد زیر را انجام دهید:

با ذی‌نفعان پروژه برای شناسایی مقادیر مناسب کار کنید.
یا مقادیر جدید را به‌صورت دستی در جدول وارد کنید یا اسکریپتی بنویسید که جدول را به‌طور خودکار پر کند (یا ترکیبی از دو راهبرد).
اعمال تبدیل Insert Data (صفحهٔ ۲۹۶) را در نظر بگیرید.

مکانیک به‌روزرسانی برنامه‌های دسترسی (Access Program Update Mechanics)

ایده‌آل این است که مکانیک به‌روزرسانی ساده باشد چون تنها کاری که باید انجام دهید استفاده از جدول جدید در برنامه(های) خود برای کار با آن جدول است. با این حال، وقتی جدول جدیدی را به‌عنوان جایگزین چند جدول دیگر معرفی می‌کنید، اغلب کشف می‌کنید جدول جدید شما طرحوارهٔ کمی متفاوت و بدتر از آن معناشناسی دادهٔ کمی متفاوت نسبت به جداول موجود دارد. در این صورت باید برنامه‌های دسترسی را بازآرایی کنید تا با نسخهٔ جدید کار کنند.

Introduce View — معرفی نما

ایجاد نما بر اساس جداول موجود در پایگاه داده.

انگیزه (Motivation)

چند دلیل وجود دارد که ممکن است بخواهید Introduce View را اعمال کنید:

خلاصه‌سازی داده برای گزارش‌دهی. بسیاری از گزارش‌ها به دادهٔ خلاصه‌شده نیاز دارند که می‌تواند از طریق تعریف نما تولید شود.
جایگزینی خواندن‌های تکراری. چند برنامهٔ بیرونی، یا stored procedure، اغلب همان پرس‌وجوی بازیابی را پیاده‌سازی می‌کنند. این پرس‌وجوها می‌توانند با یک جدول یا نمای فقط-خواندنی مشترک جایگزین شوند.
امنیت داده. نما می‌تواند برای دسترسی فقط-خواندنی کاربران نهایی به داده استفاده شود، بدون امتیاز به‌روزرسانی.
encapsulate کردن دسترسی به جدول. برخی سازمان‌ها دسترسی به جداول را با تعریف نماهای قابل به‌روزرسانی که برنامه‌های بیرونی به‌جای جداول منبع به آن‌ها دسترسی دارند encapsulate می‌کنند. این به سازمان امکان می‌دهد به‌راحتی بازآرایی‌های پایگاه داده مانند Rename Column (صفحهٔ ۱۰۹) یا Rename Table (صفحهٔ ۱۱۳) را بدون تأثیر بر برنامه‌های بیرونی انجام دهد، چون نماها لایهٔ encapsulation بین جداول و برنامه اضافه می‌کنند.
کاهش تکرار SQL. وقتی پرس‌وجوهای SQL پیچیده در برنامه دارید، رایج است بخش‌هایی از SQL در بسیاری جاها تکرار شده باشند. در این صورت باید نماها را معرفی کنید تا SQL تکراری استخراج شود، همان‌طور که در بخش مثال نشان داده شده.

معاوضه‌های بالقوه (Potential Tradeoffs)

دو چالش اصلی در معرفی نما وجود دارد. اول، عملکرد joinهای تعریف‌شده توسط نما ممکن است برای کاربران نهایی شما قابل قبول نباشد و رویکرد دیگری مانند بازآرایی Introduce Read-Only Table (صفحهٔ ۲۵۱) لازم شود. دوم، افزودن نمای جدید coupling درون طرحوارهٔ پایگاه داده را افزایش می‌دهد — همان‌طور که در شکل ۱۱.۴ می‌بینید، تعریف نما به تعاریف طرحوارهٔ جدول(ها) وابسته است.

شکل ۱۱.۴. معرفی نمای CustomerPortfolio.

[View full size image]

مکانیک به‌روزرسانی طرحواره (Schema Update Mechanics)

برای به‌روزرسانی طرحوارهٔ پایگاه داده هنگام انجام Introduce View، باید نما را از طریق دستور CREATE VIEW معرفی کنید. شکل ۱۱.۴ مثالی را نشان می‌دهد که نمای CustomerPortfolio بر اساس جداول Customer، Account و Insurance است تا کسب‌وکار انجام‌شده با هر مشتری را خلاصه کند. این راه آسان‌تری برای پرس‌وجوهای ad-hoc کاربران نهایی فراهم می‌کند. کد زیر DDL معرفی نمای CustomerPortfolio را نشان می‌دهد:

sql

CREATE VIEW CustomerPortfolio (
  CustomerID
  Name
  PhoneNumber
  AccountsTotalBalance
  InsuranceTotalPayment
  InsuranceTotalValue
) AS SELECT
  Customer.CustomerID,
  Customer.Name,
  Customer.PhoneNumber,
  SUM(Account.Balance),
  SUM(Insurance.Payment),
  SUM(Insurance.Value)
  FROM
    Customer,Account,Insurance
  WHERE
    Customer.CustomerID=Account.CustomerID
    AND Customer.CustomerID=Insurance.CustomerID

;

مکانیک مهاجرت داده (Data-Migration Mechanics)

با این بازآرایی پایگاه داده داده‌ای برای مهاجرت وجود ندارد.

مکانیک به‌روزرسانی برنامه‌های دسترسی (Access Program Update Mechanics)

مکانیک به‌روزرسانی به موقعیت بستگی دارد. اگر نما را برای جایگزینی کد SQL بازیابی مشترک در برنامه‌های دسترسی معرفی می‌کنید، باید آن کد را متناسباً بازآرایی کنید تا به‌جای آن از نمای جدید استفاده کند. اگر نما را برای اهداف گزارش‌دهی معرفی می‌کنید، گزارش‌های جدید باید نوشته شوند تا از آن نما بهره ببرند. برای برنامه‌هایی که به نما دسترسی دارند، نما مانند جدول فقط-خواندنی به نظر می‌رسد.

وقتی کد SQL در برنامه تکرار شده، پتانسیل بیشتری برای باگ وجود دارد چون وقتی SQL را در یک جا تغییر می‌دهید، باید تغییرات مشابهی در همهٔ تکرارها اعمال کنید. برای مثال، نمونه‌هایی از کد SQL برنامه را در نظر بگیرید:

sql

SELECT Customer.CustomerID, SUM(Insurance.Payment), SUM(Insurance.Value)
FROM Customer, Insurance
WHERE
  Customer.CustomerID=Insurance.CustomerID
  AND Customer.Status = 'ACTIVE'
  AND Customer.InBusinessSince <= TodaysDateLastYear
GROUP BY Customer.CustomerID
;

SELECT Customer.CustomerID, SUM(Account.Balance)
FROM Customer, Account
WHERE
  Customer.CustomerID=Account.CustomerID
  AND Customer.Status = 'ACTIVE'
  AND Customer.InBusinessSince <= TodaysDateLastYear
GROUP BY Customer.CustomerID

همان‌طور که در دو مثال کد پیشین می‌بینید، بخش انتخاب مشتری فعال تکرار شده. می‌توانیم نمایی ایجاد کنیم که این SQL تکراری را در نما استخراج کند و از نما در این SQLها استفاده کنید، تا وقتی SQL انتخاب مشتری فعال تغییر می‌کند، مجبور نباشید آن را چند بار تغییر دهید:

sql

CREATE OR REPLACE VIEW ActiveCustomer
SELECT Customer.CustomerID
FROM Customer
WHERE
  Customer.Status = 'ACTIVE'
  AND Customer.InBusinessSince <= TodaysDateLastYear
;

SELECT ActiveCustomer.CustomerID,
SUM(Insurance.Payment), SUM(Insurance.Value)
FROM ActiveCustomer, Insurance
WHERE ActiveCustomer.CustomerID=Insurance.CustomerID
GROUP BY ActiveCustomer.CustomerID
;

SELECT ActiveCustomer.CustomerID, SUM(Account.Balance)
FROM ActiveCustomer, Account

WHERE ActiveCustomer.CustomerID=Account.CustomerID
GROUP BY ActiveCustomer.CustomerID
;

Update Data — به‌روزرسانی داده

به‌روزرسانی داده در جدول موجود.

انگیزه (Motivation)

ممکن است به‌دلایل زیر نیاز به اعمال Update Data داشته باشید:

بازسازمان‌دهی جدول. وقتی Rename Table (صفحهٔ ۱۱۳)، Rename Column (صفحهٔ ۱۰۹)، Move Column (صفحهٔ ۱۰۳)، Split Table (صفحهٔ ۱۴۵)، Split Column (صفحهٔ ۱۴۰)، Merge Tables (صفحهٔ ۹۶) یا Merge Columns (صفحهٔ ۹۲) را اعمال می‌کنید، ممکن است مجبور شوید Update Data را برای بازسازمان‌دهی داده در جداول موجود اعمال کنید.
فراهم کردن داده جایی که وجود نداشت. هنگام اعمال تبدیل‌هایی مانند Introduce New Column (صفحهٔ ۳۰۱)، ممکن است برای ستون تازه‌افزوده در پایگاه‌های دادهٔ تولید موجود نیاز به فراهم کردن داده داشته باشید. برای مثال، اگر ستون Country را به جدول Address اضافه کردید، باید آن را با مقادیر مناسب پر کنید.
تغییر دادهٔ مرجع. وقتی قواعد کسب‌وکار تغییر می‌کنند، نیاز به تغییر برخی داده‌های مرجع/lookup وجود دارد. برای مثال، به‌دلیل تغییر در اصطلاحات کسب‌وکار باید مقدار AccountType.Name را از 'Private' به 'Private Banking' تغییر دهید.
پشتیبانی از تغییر ستون. بازآرایی‌هایی مانند Apply Standard Codes (صفحهٔ ۱۵۷) و Apply Standard Types (صفحهٔ ۱۶۲) اغلب به‌روزرسانی مقادیر ذخیره‌شده در ستون نیاز دارند. بازآرایی اول اغلب مقادیر استفاده‌شده در یک ستون را یکپارچه می‌کند — برای مثال «US»، «USA» و «U.S.» به مقدار واحد «USA» تبدیل می‌شوند. بازآرایی دوم اغلب تبدیل مقادیر داده را لازم می‌کند، مثلاً از عددی به کاراکتری.
اصلاح دادهٔ تراکنشی. به‌خاطر نقص در برنامه یا پایگاه دادهٔ مستقر، ممکن است نتایج نامعتبری دریافت کنید که باید در روند رفع نقص(ها) تغییر داده شوند. برای مثال، برنامه ممکن است مبلغ بهرهٔ نادرستی در جدول Charges برای مشتری بر اساس داده در جدول InterestRate پر کرده باشد؛ در روند رفع این نقص باید جدول InterestRate و جدول Charges را برای انعکاس مقدار صحیح به‌روز کنید.

معاوضه‌های بالقوه (Potential Tradeoffs)

به‌روزرسانی داده در جداول می‌تواند پیچیده باشد، به‌ویژه وقتی دادهٔ مرجع را به‌روز می‌کنید. برای مثال، فرض کنید جدول Account به داده در جدول AccountType ارجاع می‌دهد. داده‌ای که در AccountType به‌روز می‌کنید باید مقادیری داشته باشد که برای دادهٔ موجود در Account معنا دارند. هنگام به‌روزرسانی داده باید اطمینان حاصل کنید فقط ردیف‌های صحیح — و همهٔ ردیف‌های صحیح — به‌روز می‌شوند.

مکانیک به‌روزرسانی طرحواره (Schema Update Mechanics)

با این تبدیل طرحوارهٔ پایگاه داده تغییر نمی‌کند.

مکانیک مهاجرت داده (Data-Migration Mechanics)

وقتی مقادیر کمی داده باید به‌روز شود، احتمالاً یک اسکریپت SQL ساده که جدول(های) هدف را به‌روز می‌کند کافی است. برای مقادیر زیاد دادهٔ قابل به‌روزرسانی، باید رویکرد پیچیده‌تری اتخاذ کنید، مانند استفاده از ابزار extract-transform-load (ETL)، به‌ویژه وقتی داده بر اساس الگوریتم‌های پیچیده از دادهٔ جدول موجود مشتق می‌شود. مسائل مهم برای در نظر گرفتن عبارت‌اند از:

آیا دادهٔ منبع از جداول برنامهٔ موجود فراهم می‌شود، یا داده توسط کاربران کسب‌وکار شما فراهم می‌شود؟
آیا مقادیر توسط ذی‌نفع(ان) پروژه پذیرفته شده‌اند؟
کدام ردیف‌ها باید به‌روز شوند؟
کدام ستون‌های آن ردیف‌ها؟
چه وابستگی‌هایی وجود دارد؟

شکل ۱۱.۵ نشان می‌دهد چگونه در جدول AccountType که حساب‌های کارگزاری را نشان می‌دهد به‌روزرسانی می‌کنیم. این AccountType قرارداد نام‌گذاری جدیدی را پشتیبانی می‌کند که ابتدا باید آزمایش شود و سپس در تولید مستقر گردد. کد زیر DML به‌روزرسانی داده در جدول AccountType را نشان می‌دهد:

شکل ۱۱.۵. به‌روزرسانی جدول AccountType با نام‌های جدید.

sql

UPDATE AccountType SET Name = 'Chequing'
  WHERE AccountTypeID=1;

UPDATE AccountType SET Name = 'Private Banking'
  WHERE AccountTypeID=3;

مکانیک به‌روزرسانی برنامه‌های دسترسی (Access Program Update Mechanics)

وقتی Update Data در نتیجهٔ بازآرایی دیگری در پایگاه داده اعمال می‌شود، برنامه‌های بیرونی باید برای انعکاس آن بازآرایی به‌روز شده باشند. وقتی Update Data برای پشتیبانی از تغییر داده در طرحوارهٔ موجود اعمال می‌شود، ممکن است کد بیرونی نیاز به تغییر داشته باشد.

اول، ممکن است لازم باشد عبارت‌های SELECT را به‌روز کنید تا مقادیر صحیح در بند WHERE داشته باشند. برای مثال، فرض کنید مقادیر را در جدول AccountType برای ردیفی که AccountType.Name برابر «Private» بود به‌روز کرده‌اید و اکنون «Private Banking» تعریف شده.

به‌طور مشابه، ممکن است لازم باشد کد منبعی را که مقادیر ویژگی‌های داده را اعتبارسنجی می‌کند به‌روز کنید. برای مثال، ممکن است کدی داشته باشید که سعی می‌کند اعتبارسنجی کند AccountType «Private» است. اکنون آن کد باید تغییر کند و در منطق شما اعتبارسنجی کند AccountType «Private Banking» است.

تعریف نمای زیر نشان می‌دهد بخش‌های متأثر برنامه چگونه باید تغییر کنند وقتی نوع حساب «Private» به «Private Banking» تغییر می‌کند:

sql

//Before view
CREATE OR REPLACE VIEW PrivateAccounts AS
SELECT
  Account.AccountId,
  Account.CustomerId,
  Account.StartDate,
  Account.Balance,
  Account.isPrimary
FROM
  Account, AccountType
WHERE
  Account.AccountTypeId = AccountType.AccountTypeId
  AND AccountType.Name = 'Private';
;

//After view
CREATE OR REPLACE VIEW PrivateAccounts AS
SELECT
  Account.AccountId,
  Account.CustomerId,
  Account.StartDate,
  Account.Balance,
  Account.isPrimary
FROM
  Account, AccountType
WHERE
  Account.AccountTypeId = AccountType.AccountTypeId
  AND AccountType.Name = 'Private Banking'
;

پیوست. نمادگذاری مدل‌سازی داده UML

این پیوست نمادگذاری مدل‌سازی دادهٔ فیزیکی به‌کاررفته در سراسر کتاب را مرور می‌کند. ما از زیرمجموعه‌ای از نمادگذاری توصیف‌شده در پروفایل Unified Modeling Language (UML) استفاده کرده‌ایم که در ابتدا در Agile Database Techniques (Ambler 2003) ارائه شد و اکنون آنلاین در www.agiledata.org/essays/umlDataModelingProfile.html نگه‌داری می‌شود.

شکل A.1 نمادگذاری پایه برای جداول درون طرحوارهٔ پایگاه داده را توصیف می‌کند. جداول به‌صورت جعبه‌هایی با یک، دو یا سه بخش نمایش داده می‌شوند. بخش اول، که نام جدول را دارد، اجباری است. دو بخش دیگر اختیاری‌اند؛ دومی ستون‌های جدول و سومی triggerهای مرتبط با جدول (در صورت وجود) را فهرست می‌کند. در فهرست ستون‌ها، فقط نام‌ها اجباری‌اند؛ در سراسر این کتاب، برای سادگی، اغلب نام ستون‌ها را فهرست می‌کنیم اما نه نوع آن‌ها. وقتی ستونی بخشی از کلید است، یک یا چند stereotype UML که در جدول A.1 توصیف شده‌اند، دنبال آن می‌آید.

شکل A.1. نمادگذاری برای مدل‌سازی جداول.

[View full size image]

جدول A.1. Stereotypeها برای کلیدها

Stereotype	کاربرد
PK	نشان می‌دهد ستون بخشی از کلید اصلی جدول است.
FK	نشان می‌دهد ستون بخشی از کلید خارجی به جدول دیگر است.
AK	نشان می‌دهد ستون بخشی از کلید جایگزین است، که گاه کلید ثانویه هم نامیده می‌شود.
Natural	نشان می‌دهد کلید ویژگی طبیعی موجودیت (مثلاً Policy) ذخیره‌شده در جدول است. این stereotype به‌ندرت اختصاص داده می‌شود — اگر ستون کلید به‌عنوان surrogate برچسب نخورده باشد، فرض بر طبیعی بودن آن است.
Surrogate	نشان می‌دهد کلید مصنوعی (غیرطبیعی) است.

امکان نشان دادن اطلاعات بیشتر مربوط به کلیدها وجود دارد، همان‌طور که در شکل A.2 می‌بینید. جدول PolicyNotes سه کلید دارد: کلید اصلی متشکل از ستون‌های PolicyNumber و NoteNumber، اولین کلید جایگزین متشکل از PolicyOID و NoteNumber، و دومین کلید جایگزین ستون PolicyNoteOID. وقتی کلید composite است — یعنی از چند ستون تشکیل شده — ممکن است مهم باشد ترتیب ستون‌ها در کلید را نشان دهید تا indexهای متناظر به‌درستی تعریف شوند. ترتیب از طریق مقدار نام‌دار order نشان داده می‌شود. برای مثال، می‌بینیم ستون PolicyNumber اولین ستون در کلید اصلی و NoteNumber دومین ستون است. چون به نمودارها شلوغی اضافه می‌کند، باید ترتیب ستون‌ها را فقط وقتی لازم است نشان دهید.

شکل A.2. نمادگذاری برای مدل‌سازی جزئیات کلیدها.

[View full size image]

رابطه‌ها، که اغلب association نامیده می‌شوند، به‌صورت خطوط پیوسته بین دو جدول مدل‌سازی می‌شوند. در شکل A.3، می‌گویید یک مشتری ممکن است صفر یا بیشتر policy داشته باشد و یک policy متعلق به یک مشتری است. پیکان کنار برچسب owns روی رابطه بین Customer و Account جهت خواندن رابطه را نشان می‌دهد؛ این نماد اختیاری است و فقط وقتی استفاده شود که جهت خواندن واضح نباشد. قرارداد رایج این است که برچسب را طوری بنویسید که از چپ به راست یا از بالا به پایین، بسته به مورد، معنا داشته باشد (Ambler 2005b). می‌دانیم مشتریان ممکن است صفر یا بیشتر policy داشته باشند — به‌خاطر نشانگر multiplicity برابر 0..* روی خط رابطه کنار جدول Policy — و هر policy فقط متعلق به یک مشتری است (همان‌طور که نشانگر multiplicity دیگر نشان می‌دهد). جدول A.2 نشانگرهای multiplicity مختلف را خلاصه می‌کند.

شکل A.3. نمادگذاری برای مدل‌سازی رابطه‌ها.

جدول A.2. Multiplicityهای UML

Multiplicity	معنی
0..1	صفر یا یک
1	فقط یک
0..*	صفر یا بیشتر
1..*	یک یا بیشتر
*	یک یا بیشتر
n	فقط n (که n > 1)
0..n	صفر تا n (که n > 1)
1..n	یک تا n (که n > 1)

در شکل A.3، همچنین می‌گوییم یک مشتری به صفر یا بیشتر حساب دسترسی دارد و یک حساب توسط یک یا بیشتر مشتری دسترسی داده می‌شود. اگرچه association چندبه‌چند بین موجودیت‌های customer و account وجود دارد، نمی‌توانیم این را به‌صورت بومی در پایگاه دادهٔ رابطه‌ای پیاده‌سازی کنیم؛ از این رو جدول واسط CustomerAccount برای نگه‌داری رابطه افزوده شده. علاوه بر این، یک order item بخشی از یک order است و یک order از یک یا بیشتر order item تشکیل شده. الماس در انتهای خط نشان می‌دهد رابطه بین Order و OrderItem از نوع aggregation است، که «بخشی از» (part of) هم نامیده می‌شود. وقتی multiplicity کنار الماس نشان داده نشده، 1 فرض می‌شود. شکل A.4 چند مثال دیگر از رابطه‌ها بین جداول و نحوهٔ خواندن آن‌ها را ارائه می‌دهد.

شکل A.4. نمونه‌هایی از رابطه‌ها.

یک Customer صفر یا بیشتر policy دارد؛ یک policy متعلق به یک و فقط یک customer است.

یک order از یک یا بیشتر order item تشکیل شده و یک order item بخشی از یک order است.

یک customer به صفر یا بیشتر account دسترسی دارد و یک account توسط یک یا بیشتر customer دسترسی داده می‌شود.

یک policy note برای یک policy نوشته می‌شود و یک policy ممکن است یک policy note برای آن نوشته شده باشد.

شکل A.5 نمادگذاری چند مفهوم رایج دیگر پایگاه داده را مرور می‌کند:

شکل A.5. نمادگذاری برای مدل‌سازی stored procedure، view و index.

[View full size image]

Stored procedureها. Stored procedureها در مستطیلی دو بخشی نمایش داده می‌شوند. بخش بالایی نام پایگاه داده و stereotype Stored Procedures را نشان می‌دهد. بخش پایینی امضای stored procedureها (یا functionها) درون پایگاه داده را فهرست می‌کند.

Indexها. index به‌صورت جعبه‌ای با نام index، stereotype Index و رابطه‌های وابستگی که به ستون(های) مبنای index اشاره می‌کنند مدل‌سازی می‌شود.

Viewها. view به‌صورت مستطیلی دو بخشی نمایش داده می‌شود. بخش بالایی نام view و stereotype View را نشان می‌دهد. بخش پایینی، که اختیاری است، ستون‌های موجود در view را فهرست می‌کند.

واژه‌نامه

این واژه‌نامه اصطلاحات مهم را همان‌طور که در بافت این کتاب به کار برده‌ایم توصیف می‌کند.

Agile Data (AD) method

مجموعه‌ای از فلسفه‌ها و نقش‌ها برای تعریف چگونگی اعمال فعالیت‌های توسعهٔ داده‌محور به‌صورت چابک.

Agile Model-Driven Development (AMDD)

رویکردی بسیار تکراری به توسعه که در آن قبل از نوشتن کد منبع، مدل‌های چابک می‌سازید.

Agile Modeling (AM)

متدولوژی مبتنی بر practice با ماهیت chaordic که توصیف می‌کند چگونه در مدل‌سازی و مستندسازی مؤثر باشید.

Agile software development

رویکرد تکاملی و بسیار مشارکتی به توسعه که تمرکز بر تحویل منظم نرم‌افزار با کیفیت بالا و آزمون‌شده که بالاترین نیازهای ذی‌نفعان را برآورده می‌کند.

Agile Unified Process (AUP)

نمونه‌سازی Unified Process (UP) که practiceهای چابک رایج مانند بازآرایی پایگاه داده، Test-Driven Development و Agile Model-Driven Development را اعمال می‌کند.

Architectural refactoring

تغییری که شیوهٔ کلی تعامل برنامه‌های بیرونی با پایگاه داده را بهبود می‌دهد.

Artifact

سند، مدل، فایل، نمودار یا مورد دیگری که در طول توسعه، بهره‌برداری یا پشتیبانی سیستم تولید، اصلاح یا استفاده می‌شود.

Behavioral semantics

معنای عملکرد پیاده‌سازی‌شده درون پایگاه داده.

Code smell

دستهٔ رایج مشکل در کد منبع که نیاز به بازآرایی آن را نشان می‌دهد.

Conceptual/domain model

مدلی که موجودیت‌های اصلی کسب‌وکار و روابط بین آن‌ها را — و اختیاراً ویژگی‌ها یا مسئولیت‌های آن موجودیت‌ها — به تصویر می‌کشد.

Coupling

معیاری از وابستگی بین دو مورد؛ هرچه دو چیز coupling بیشتری داشته باشند، احتمال بیشتری وجود دارد تغییر در یکی تغییر در دیگری را لازم کند.

Crystal

خانواده‌ای خودسازگار از متدولوژی‌های چابک «نیرومند انسان» که Alistair Cockburn توسعه داده.

Data access object (DAO)

کلاسی که کد پایگاه دادهٔ لازم برای پایدارسازی کلاس کسب‌وکار متناظر را پیاده‌سازی می‌کند.

Database refactoring (اسم)

تغییری ساده در طرحوارهٔ پایگاه داده که طراحی آن را بهبود می‌دهد در حالی که هم معناشناسی رفتاری و هم اطلاعاتی را حفظ می‌کند — یعنی نمی‌توانید قابلیت جدید اضافه کنید یا قابلیت موجود را بشکنید، و نمی‌توانید دادهٔ جدید اضافه کنید یا معنای دادهٔ موجود را تغییر دهید.

Database refactoring (فعل)

فرایندی که در آن طرحوارهٔ پایگاه دادهٔ موجود را تکه‌تکه تکامل می‌دهید تا کیفیت طراحی آن بدون تغییر معناشناسی بهبود یابد.

Database regression testing

فرایندی که در آن با توسعه و سپس اجرای منظم مجموعهٔ آزمون در برابر آن، اطمینان حاصل می‌کنید طرحوارهٔ پایگاه داده واقعاً کار می‌کند.

Database schema

جنبه‌های ساختاری، مانند تعاریف جدول و view، و جنبه‌های عملکردی، مانند متدهای پایگاه داده.

Database smell

مشکل رایج درون طرحوارهٔ پایگاه داده که نیاز بالقوه به بازآرایی آن را نشان می‌دهد.

Database transformation

تغییری در طرحوارهٔ پایگاه داده که ممکن است معناشناسی طرحواره را تغییر دهد یا ندهد. بازآرایی پایگاه داده نوعی تبدیل پایگاه داده است.

Data definition language (DDL)

دستوراتی که پایگاه داده پشتیبانی می‌کند و ایجاد، حذف یا اصلاح ساختارها (مانند جداول رابطه‌ای یا کلاس‌ها) درون آن را ممکن می‌سازد.

Data manipulation language (DML)

دستوراتی که پایگاه داده پشتیبانی می‌کند و دسترسی به داده درون آن — شامل ایجاد، بازیابی، به‌روزرسانی و حذف آن داده — را ممکن می‌سازد.

Data quality refactoring

تغییری که کیفیت اطلاعات موجود در پایگاه داده را بهبود می‌دهد.

Demo sandbox

محیط فنی که نرم‌افزار را در آن مستقر می‌کنید تا برای افراد خارج از تیم توسعهٔ فوری خود نمایش دهید.

Deployment window

نقطهٔ زمانی مشخص که در آن مستقر کردن سیستم در تولید مجاز است. اغلب release window هم نامیده می‌شود.

Deprecation period

به Transition period مراجعه کنید.

Development sandbox

محیط فنی که متخصصان IT در آن نرم‌افزار می‌نویسند، آزمایش می‌کنند و می‌سازند.

Dynamic System Development Method (DSDM)

متد چابکی که formalization روش‌های Rapid Application Development (RAD) دههٔ ۱۹۸۰ است.

Enterprise Unified Process (EUP)

گسترش Rational Unified Process (RUP) که نیازهای بین‌پروژه‌ای/سیستمی را پوشش می‌دهد.

Evolutionary data modeling

فرایندی که در آن جنبه‌های دادهٔ سیستم را به‌صورت تکراری و افزایشی مدل می‌کنید تا طرحوارهٔ پایگاه داده هم‌گام با کد برنامه تکامل یابد.

Evolutionary software development

رویکردی که در آن هم تکراری و هم افزایشی کار می‌کنید.

Extract-transform-load (ETL)

رویکردی برای انتقال داده از یک منبع به منبع دیگر که در آن داده در طول فرایند «پاک‌سازی» می‌شود.

Extreme Programming (XP)

متد توسعهٔ چابک منضبط و آگاهانه که بر فعالیت‌های حیاتی لازم برای ساخت نرم‌افزار تمرکز دارد.

Feature-Driven Development (FDD)

متد توسعهٔ چابک مبتنی بر تکرارهای کوتاه که توسط مدل دامنهٔ شیء مشترک و featureها (نیازمندی‌های کوچک) هدایت می‌شود.

Incremental software development

رویکرد توسعهٔ نرم‌افزار که پروژه را به چند release به‌جای یک release «یک‌باره» سازمان‌دهی می‌کند.

Informational semantics

معنای اطلاعات درون پایگاه داده از دیدگاه کاربران آن اطلاعات.

Iteration

دورهٔ زمانی، اغلب یک یا دو هفته، که در آن نرم‌افزار در حال کار نوشته می‌شود. development cycle هم نامیده می‌شود.

Iterative software development

رویکرد غیرسریالی به توسعه که در آن احتمالاً در هر روز کمی تعریف نیازمندی، کمی مدل‌سازی، کمی برنامه‌نویسی یا کمی آزمون انجام می‌دهید.

Method

درون پایگاه داده، stored procedure، stored function یا trigger.

Method refactoring

تغییری در متد که کیفیت آن را بهبود می‌دهد. بسیاری از بازآرایی‌های کد برای متدهای پایگاه داده قابل اعمال‌اند.

Model storming

انفجار کوتاه مدل‌سازی، اغلب ۵ تا ۱۵ دقیقه، که در آن دو یا چند نفر با هم بخشی از دامنهٔ مسئله یا راه‌حل را کاوش می‌کنند. جلسات model storming بلافاصله با جلسات کدنویسی (اغلب چند ساعت یا چند روز) دنبال می‌شوند.

Multi-application database

پایگاه داده‌ای که توسط چند برنامه دسترسی داده می‌شود، یکی یا بیشتر از آن‌ها خارج از حوزهٔ کنترل شما.

Object-relational mapping (ORM)

تعریف رابطه(هایی) بین جنبه‌های دادهٔ طرحوارهٔ شیء (مثلاً کلاس‌های Java) و طرحوارهٔ پایگاه دادهٔ رابطه‌ای.

Production environment

محیط فنی که کاربران نهایی یک یا چند سیستم را در آن اجرا می‌کنند.

Production phase

بخشی از چرخهٔ عمر سیستم که سیستم توسط کاربران نهایی اجرا می‌شود.

Project integration sandbox

محیط فنی که کد همهٔ اعضای تیم پروژه در آن کامپایل و آزمون می‌شود.

Rapid Application Development (RAD)

رویکرد توسعهٔ نرم‌افزار با ماهیت بسیار تکاملی که معمولاً شامل مقادیر قابل‌توجهی از نمونه‌سازی رابط کاربری است.

Rational Unified Process (RUP)

فرایند توسعهٔ نرم‌افزار چهارفازی دقیق که IBM Rational ایجاد کرده و ماهیت تکاملی دارد.

Refactoring (اسم)

تغییری ساده در کد منبع که معناشناسی رفتاری آن را حفظ می‌کند: هنگام بازآرایی نه قابلیت اضافه می‌کنید و نه حذف. بازآرایی فقط طراحی کد را بهبود می‌دهد — نه بیشتر و نه کمتر.

Refactoring (فعل)

تکنیک برنامه‌نویسی که امکان تکامل تدریجی کد در طول زمان را می‌دهد تا رویکرد تکاملی به برنامه‌نویسی داشته باشید.

Referential integrity

اطمینان از اینکه ارجاع از یک موجودیت به موجودیت دیگر معتبر است. اگر موجودیت A به موجودیت B ارجاع دهد، موجودیت B وجود دارد. اگر موجودیت B حذف شود، همهٔ ارجاعات به موجودیت B نیز باید حذف شوند.

Referential integrity refactoring

تغییری که اطمینان می‌دهد ردیف ارجاع‌شده در جدول دیگر وجود دارد و/یا ردیفی که دیگر لازم نیست به‌طور مناسب حذف می‌شود.

Regression test suite

مجموعه‌ای از آزمون‌ها که به‌طور منظم در برابر سیستم اجرا می‌شوند تا تأیید کنند طبق آزمون‌ها کار می‌کند.

Sandbox

محیط کاملاً عملیاتی که در آن سیستم ساخته، آزمون و/یا اجرا می‌شود.

Scrum

متد چابکی که تمرکز آن بر مدیریت پروژه و مدیریت نیازمندی است. Scrum اغلب با XP ترکیب می‌شود.

Serial development

رویکردی که در آن مدل‌های نسبتاً دقیق قبل از «مجاز بودن» شروع پیاده‌سازی ساخته می‌شوند. waterfall development هم نامیده می‌شود.

Single-application database

پایگاه داده‌ای که توسط یک برنامه دسترسی داده می‌شود که توسط همان تیمی «مالک» است که پایگاه داده را مالک است.

Standup meeting

جلسهٔ کوتاهی که با اعضای تیم در حالت ایستاده برگزار می‌شود و گزارش وضعیت کارهای دیروز، برنامهٔ امروز، مشکلات، تغییرات معماری و سایر موارد مهم برای اطلاع‌رسانی به تیم ارائه می‌شود.

Stereotype

سازهٔ UML که کاربرد رایج یک عنصر مدل‌سازی را نشان می‌دهد. stereotypeها برای گسترش UML به‌صورت سازگار به کار می‌روند.

Structural refactoring

تغییری در تعریف یک یا چند جدول یا view.

Test-Driven Development (TDD)

ترکیب TFD و بازآرایی.

Test-First Development (TFD)

رویکرد تکاملی به توسعه که در آن ابتدا باید آزمونی بنویسید که شکست بخورد، سپس کد عملکردی جدید تا آزمون پاس شود. Test-First Programming هم نامیده می‌شود.

Transaction

واحد کاری واحد که یا کاملاً موفق می‌شود یا کاملاً شکست می‌خورد. تراکنش ممکن است یک یا چند به‌روزرسانی روی شیء، یک یا چند خواندن، یک یا چند حذف، یک یا چند درج، یا هر ترکیبی از آن‌ها باشد.

Transition period

زمانی که هم طرحوارهٔ قدیم و هم طرحوارهٔ جدید به‌صورت موازی پشتیبانی می‌شوند. deprecation period هم نامیده می‌شود.

Trigger

متد پایگاه داده که به‌طور خودکار در نتیجهٔ فعالیت Data Manipulation Language (DML) درون مکانیزم persistence فراخوانی می‌شود.

Unified Modeling Language (UML)

تعریف زبان مدل‌سازی استاندارد برای نرم‌افزار شیءگرا، شامل تعریف نمادگذاری مدل‌سازی و معناشناسی کاربرد آن، همان‌طور که Object Management Group (OMG) تعریف کرده.

Waterfall development

به Serial development مراجعه کنید.

XUnit

خانواده‌ای از ابزارهای آزمون واحد، شامل JUnit برای Java، VBUnit برای Visual Basic، NUnit برای .NET و OUnit برای Oracle.

منابع و مطالعهٔ پیشنهادی

Agile Alliance (2001a). Manifesto for Agile Software Development. www.agilealliance.com

Agile Alliance (2001b). Principles: The Agile Alliance. www.agilealliance.com/principles.html

Ambler, S. W. (2002). Agile Modeling: Best Practices for the Unified Process and Extreme Programming. New York: John Wiley & Sons. www.ambysoft.com/agileModeling.html

Ambler, S. W. (2003). Agile Database Techniques: Effective Strategies for the Agile Software Developer. New York: John Wiley & Sons. www.ambysoft.com/agileDatabaseTechniques.html

Ambler, S. W. (2004). The Object Primer, 3rd Edition: Agile Model Driven Development with UML 2. New York: Cambridge University Press. www.ambysoft.com/theObjectPrimer.html

Ambler, S. W. (2005a). A UML Profile for Data Modeling. www.agiledata.org/essays/umlDataModelingProfile.html

Ambler, S. W. (2005b). The Elements of UML 2.0 Style. New York: Cambridge University Press. www.ambysoft.com/elementsUMLStyle.html

Ambler, S. W. (2005c). The Agile Unified Process. www.ambysoft.com/unifiedprocess/agileUP.html

Astels D. (2003). Test Driven Development: A Practical Guide. Upper Saddle River, NJ: Prentice Hall.

Beck, K. (2003). Test Driven Development: By Example. Boston: Addison-Wesley.

Boehm, B. W., and Turner, R. (2003). Balancing Agility and Discipline: A Guide for the Perplexed. Reading, MA: Addison-Wesley Longman, Inc.

Burry, C., and Mancusi, D. (2004). How to Plan for Data Migration. Computerworld. www.computerworld.com/databasetopics/data/story/0,10801,93284,00.html

Celko, J. (1999). Joe Celko's Data & Databases: Concepts in Practice. San Francisco: Morgan Kaufmann.

Cockburn, A. (2002). Agile Software Development. Reading, MA: Addison-Wesley Longman, Inc.

Date, C. J. (2001). An Introduction to Database System, 7/e. Reading, MA: Addison-Wesley Longman, Inc.

Feathers, M. (2004). Working Effectively with Legacy Code. Boston: Addison-Wesley.

Fowler, M. (1999). Refactoring: Improving the Design of Existing Code. Menlo Park, CA: Addison-Wesley Longman.

Fowler, M., and Sadalage, P. (2003). Evolutionary Database Design. martinfowler.com/articles/evodb.html

Halpin, T. A. (2001). Information Modeling and Relational Databases: From Conceptual Analysis to Logical Design. San Francisco: Morgan Kaufmann.

Hay, D. C. (1996). Data Model Patterns: Conventions of Thought. New York: Dorset House Publishing.

Hay, D. C. (2003). Requirements Analysis: From Business Views to Architecture. Upper Saddle River, NJ: Prentice Hall.

Hernandez, M. J., and Viescas, J. L. (2000). SQL Queries for Mere Mortals: A Hands-on Guide to Data Manipulation in SQL. Reading, MA: Addison-Wesley.

Kerievsky, J. (2004). Refactoring to Patterns. Boston: Addison-Wesley.

Kyte, T. (2005). Avoiding Mutating Tables. asktom.oracle.com/~tkyte/Mutate/

Larman, C. (2004). Agile and Iterative Development: A Manager's Guide. Boston: Addison-Wesley.

Loshin, D. (2004a). Issues and Opportunities in Data Quality Management Coordination. DM Review Magazine, April 2004.

Loshin, D. (2004b). More on Information Quality ROI. The Data Administration Newsletter (TDAN.com), July 2004. www.tdan.com/nwt_issue29.htm

Manns, M. L., and Rising, L. (2005). Fearless Change: Patterns for Introducing New Ideas. Boston: Pearson Education, Ltd.

Meszaros, G. (2006). Xunit Test Patterns: Refactoring Test Code. Boston: Prentice Hall.

Muller, R. J. (1999). Database Design for Smarties: Using UML for Data Modeling. San Francisco: Morgan Kaufmann.

Mullins, C. S. (2002). Database Administration: The Complete Guide to Practices and Procedures. Reading, MA: Addison-Wesley Longman, Inc.

Pascal, F. (2000). Practical Issues in Database Management: A Reference for the Thinking Practitioner. Upper Saddle River, NJ: Addison-Wesley.

Sadalage, P., and Schuh, P. (2002). The Agile Database: Tutorial Notes. Paper presented at XP/Agile Universe 2002. Retrieved November 12, 2003 from www.xpuniverse.com

Seiner, R. (2004). Data Stewardship Performance Measures. The Data Administration Newsletter, July 2004. www.tdan.com/i029fe01.htm

Williams, L., and Kessler, R. (2002). Pair Programming Illuminated. Boston: Addison-Wesley.

فهرست بازآرایی‌ها و تبدیل‌ها

Add CRUD Methods (صفحهٔ ۲۳۲): معرفی stored procedureها (متدها) برای پیاده‌سازی ایجاد، بازیابی، به‌روزرسانی و حذف (CRUD) دادهٔ نمایندهٔ یک موجودیت کسب‌وکار.

Add Foreign Key Constraint (صفحهٔ ۲۰۴): افزودن محدودیت کلید خارجی به جدول موجود برای اعمال رابطه با جدول دیگر.

Add Lookup Table (صفحهٔ ۱۵۳): ایجاد جدول lookup برای ستون موجود.

Add Mirror Table (صفحهٔ ۲۳۶): ایجاد جدول آینه، کپی دقیق جدول موجود در یک پایگاه داده، در پایگاه دادهٔ دیگر.

Add Parameter (صفحهٔ ۲۷۸): متد موجود به اطلاعاتی نیاز دارد که قبلاً به آن پاس داده نمی‌شد.

Add Read Method (صفحهٔ ۲۴۰): معرفی متدی — در این مورد stored procedure — برای پیاده‌سازی بازیابی دادهٔ نمایندهٔ صفر یا بیشتر موجودیت کسب‌وکار از پایگاه داده.

Add Trigger For Calculated Column (صفحهٔ ۲۰۹): معرفی trigger جدید برای به‌روزرسانی مقدار موجود در ستون محاسبه‌شده.

Apply Standard Codes (صفحهٔ ۱۵۷): اعمال مجموعهٔ استاندارد مقادیر کد به یک ستون برای اطمینان از انطباق با مقادیر ستون‌های مشابه ذخیره‌شده در جای دیگر پایگاه داده.

Apply Standard Type (صفحهٔ ۱۶۲): اطمینان از اینکه نوع دادهٔ ستون با نوع دادهٔ ستون‌های مشابه دیگر درون پایگاه داده سازگار است.

Consolidate Conditional Expression (صفحهٔ ۲۸۳): ترکیب دنبالهٔ آزمون‌های شرطی در یک عبارت شرطی واحد و استخراج آن.

Consolidate Key Strategy (صفحهٔ ۱۶۸): انتخاب یک راهبرد کلید واحد برای موجودیت و اعمال سازگار آن در سراسر پایگاه داده.

Decompose Conditional (صفحهٔ ۲۸۴): استخراج متدها از شرط.

Drop Column (صفحهٔ ۷۲): حذف ستون از جدول موجود.

Drop Column Constraint (صفحهٔ ۱۷۲): حذف محدودیت ستون از جدول موجود.

Drop Default Value (صفحهٔ ۱۷۴): حذف مقدار پیش‌فرضی که پایگاه داده برای ستون جدول موجود فراهم می‌کند.

Drop Foreign Key Constraint (صفحهٔ ۲۱۳): حذف محدودیت کلید خارجی از جدول موجود تا رابطه با جدول دیگر دیگر توسط پایگاه داده اعمال نشود.

Drop Non-Nullable (صفحهٔ ۱۷۷): تغییر ستون غیرnullable موجود تا مقادیر null بپذیرد.

Drop Table (صفحهٔ ۷۷): حذف جدول موجود از پایگاه داده.

Drop View (صفحهٔ ۷۹): حذف view موجود.

Encapsulate Table With View (صفحهٔ ۲۴۳): پوشاندن دسترسی به جدول موجود با view.

Extract Method (صفحهٔ ۲۸۵): تبدیل قطعه کد به متدی که نام آن هدف متد را توضیح می‌دهد.

Insert Data (صفحهٔ ۲۹۶): درج داده در جدول موجود.

Introduce Calculated Column (صفحهٔ ۸۱): معرفی ستون جدید بر اساس محاسباتی که شامل داده در یک یا چند جدول است.

Introduce Calculation Method (صفحهٔ ۲۴۵): معرفی متد جدید، معمولاً stored function، که محاسبه‌ای را با استفاده از دادهٔ ذخیره‌شده در پایگاه داده پیاده‌سازی می‌کند.

Introduce Cascading Delete (صفحهٔ ۲۱۵): اطمینان از اینکه پایگاه داده هنگام حذف رکورد «والد»، رکوردهای «فرزند» مناسب را به‌طور خودکار حذف می‌کند.

Introduce Column Constraint (صفحهٔ ۱۸۰): معرفی محدودیت ستون در جدول موجود.

Introduce Common Format (صفحهٔ ۱۸۳): اعمال قالب سازگار به همهٔ مقادیر داده در ستون جدول موجود.

Introduce Default Value (صفحهٔ ۱۸۶): واگذاری فراهم کردن مقدار پیش‌فرض برای ستون جدول موجود به پایگاه داده.

Introduce Hard Delete (صفحهٔ ۲۱۹): حذف ستون موجود که نشان می‌دهد ردیف حذف شده و در عوض حذف واقعی ردیف.

Introduce Index (صفحهٔ ۲۴۸): معرفی index جدید از نوع یکتا یا غیریکتا.

Introduce New Column (صفحهٔ ۳۰۱): معرفی ستون جدید در جدول موجود.

Introduce New Table (صفحهٔ ۳۰۴): معرفی جدول جدید در پایگاه دادهٔ موجود.

Introduce Read-Only Table (صفحهٔ ۲۵۱): ایجاد مخزن دادهٔ فقط-خواندنی بر اساس جداول موجود در پایگاه داده.

Introduce Soft Delete (صفحهٔ ۲۲۲): معرفی پرچمی به جدول موجود که نشان می‌دهد ردیف حذف شده به‌جای حذف واقعی ردیف.

Introduce Surrogate Key (صفحهٔ ۸۵): جایگزینی کلید طبیعی موجود با کلید surrogate.

Introduce Trigger For History (صفحهٔ ۲۲۷): معرفی trigger جدید برای ثبت تغییرات داده برای اهداف تاریخی یا audit.

Introduce Variable (صفحهٔ ۲۸۷): قرار دادن نتیجهٔ عبارت، یا بخش‌هایی از عبارت، در متغیر موقت با نامی که هدف را توضیح می‌دهد.

Introduce View (صفحهٔ ۳۰۶): ایجاد view بر اساس جداول موجود در پایگاه داده.

Make Column Non-Nullable (صفحهٔ ۱۸۹): تغییر ستون موجود تا هیچ مقدار null نپذیرد.

Merge Columns (صفحهٔ ۹۲): ادغام دو یا چند ستون در یک جدول.

Merge Tables (صفحهٔ ۹۶): ادغام دو یا چند جدول در یک جدول.

Migrate Method From Database (صفحهٔ ۲۵۷): میزبانی مجدد متد پایگاه دادهٔ موجود (stored procedure، stored function یا trigger) در برنامه(هایی) که در حال حاضر آن را فراخوانی می‌کنند.

Migrate Method To Database (صفحهٔ ۲۶۱): میزبانی مجدد منطق برنامهٔ موجود در پایگاه داده.

Move Column (صفحهٔ ۱۰۳): مهاجرت ستون جدول، با همهٔ دادهٔ آن، به جدول موجود دیگر.

Move Data (صفحهٔ ۱۹۲): انتقال دادهٔ موجود در جدول، یا همه یا زیرمجموعه‌ای از ستون‌های آن، به جدول موجود دیگر.

Parameterize Method (صفحهٔ ۲۷۸): ایجاد یک متد که از پارامتر برای مقادیر مختلف استفاده می‌کند.

Remove Control Flag (صفحهٔ ۲۸۹): استفاده از return یا break به‌جای متغیری که به‌عنوان پرچم کنترل عمل می‌کند.

Remove Middle Man (صفحهٔ ۲۸۹): واداشتن فراخواننده به فراخوانی مستقیم متد.

Remove Parameter (صفحهٔ ۲۷۹): حذف پارامتری که دیگر توسط بدنهٔ متد استفاده نمی‌شود.

Rename Column (صفحهٔ ۱۰۹): تغییر نام ستون جدول موجود با نامی که هدف آن را توضیح می‌دهد.

Rename Method (صفحهٔ ۲۷۹): تغییر نام متد موجود با نامی که هدف آن را توضیح می‌دهد.

Rename Table (صفحهٔ ۱۱۳): تغییر نام جدول موجود با نامی که هدف آن را توضیح می‌دهد.

Rename View (صفحهٔ ۱۱۷): تغییر نام view موجود با نامی که هدف آن را توضیح می‌دهد.

Reorder Parameters (صفحهٔ ۲۸۱): تغییر ترتیب پارامترهای متد.

Replace Column (صفحهٔ ۱۲۶): جایگزینی ستون غیرکلیدی موجود با ستون جدید.

Replace LOB With Table (صفحهٔ ۱۲۰): جایگزینی ستون large object (LOB) که دادهٔ ساخت‌یافته دارد با جدول جدید یا در همان جدول.

Replace Literal With Table Lookup (صفحهٔ ۲۹۰): جایگزینی ثابت‌های کد با مقادیر از جداول پایگاه داده.

Replace Method(s) With View (صفحهٔ ۲۶۵): ایجاد view بر اساس یک یا چند متد پایگاه دادهٔ موجود (stored procedure، stored function یا trigger) درون پایگاه داده.

Replace Nested Conditional With Guard Clauses (صفحهٔ ۲۹۲): حذف شرط‌های if تو در تو با مجموعه‌ای از عبارت‌های IF جداگانه.

Replace One-To-Many With Associative Table (صفحهٔ ۱۳۰): جایگزینی association یک‌به‌چند بین دو جدول با جدول واسط.

Replace Parameter With Explicit Methods (صفحهٔ ۲۸۲): ایجاد متد جداگانه برای هر مقدار پارامتر.

Replace Surrogate Key With Natural Key (صفحهٔ ۱۳۵): جایگزینی کلید surrogate با کلید طبیعی موجود.

Replace Type Code With Property Flags (صفحهٔ ۱۹۶): جایگزینی ستون کد با پرچم‌های ویژگی فردی، معمولاً به‌صورت ستون‌های Boolean، درون همان جدول.

Replace View With Method(s) (صفحهٔ ۲۶۸): جایگزینی view موجود با یک یا چند متد موجود (stored procedure، stored function یا trigger) درون پایگاه داده.

Split Column (صفحهٔ ۱۴۰): تقسیم ستون به یک یا چند ستون در یک جدول.

Split Table (صفحهٔ ۱۴۵): تقسیم عمودی (مثلاً بر اساس ستون‌ها) جدول موجود به یک یا چند جدول.

Split Temporary Variable (صفحهٔ ۲۹۲): ایجاد متغیر موقت جداگانه برای هر انتساب.

Substitute Algorithm (صفحهٔ ۲۹۳): جایگزینی بدنهٔ متد با الگوریتم جدید.

Update Data (صفحهٔ ۳۱۰): به‌روزرسانی داده در جدول موجود.

Use Official Data Source (صفحهٔ ۲۷۱): استفاده از منبع دادهٔ رسمی برای موجودیت داده‌شده، به‌جای منبعی که در حال حاضر استفاده می‌کنید.

[View full size image]

فصل ۱۱ — تبدیل‌ها ​

Insert Data — درج داده ​

انگیزه (Motivation) ​

معاوضه‌های بالقوه (Potential Tradeoffs) ​

مکانیک به‌روزرسانی طرحواره (Schema Update Mechanics) ​

مکانیک مهاجرت داده (Data-Migration Mechanics) ​

مکانیک به‌روزرسانی برنامه‌های دسترسی (Access Program Update Mechanics) ​

Introduce New Column — معرفی ستون جدید ​

انگیزه (Motivation) ​

معاوضه‌های بالقوه (Potential Tradeoffs) ​

مکانیک به‌روزرسانی طرحواره (Schema Update Mechanics) ​

مکانیک مهاجرت داده (Data-Migration Mechanics) ​

مکانیک به‌روزرسانی برنامه‌های دسترسی (Access Program Update Mechanics) ​

Introduce New Table — معرفی جدول جدید ​

انگیزه (Motivation) ​

معاوضه‌های بالقوه (Potential Tradeoffs) ​

مکانیک به‌روزرسانی طرحواره (Schema Update Mechanics) ​

مکانیک مهاجرت داده (Data-Migration Mechanics) ​

مکانیک به‌روزرسانی برنامه‌های دسترسی (Access Program Update Mechanics) ​

Introduce View — معرفی نما ​

انگیزه (Motivation) ​

معاوضه‌های بالقوه (Potential Tradeoffs) ​

مکانیک به‌روزرسانی طرحواره (Schema Update Mechanics) ​

مکانیک مهاجرت داده (Data-Migration Mechanics) ​

مکانیک به‌روزرسانی برنامه‌های دسترسی (Access Program Update Mechanics) ​

Update Data — به‌روزرسانی داده ​

انگیزه (Motivation) ​

معاوضه‌های بالقوه (Potential Tradeoffs) ​

مکانیک به‌روزرسانی طرحواره (Schema Update Mechanics) ​

مکانیک مهاجرت داده (Data-Migration Mechanics) ​

مکانیک به‌روزرسانی برنامه‌های دسترسی (Access Program Update Mechanics) ​

پیوست. نمادگذاری مدل‌سازی داده UML ​

واژه‌نامه ​

منابع و مطالعهٔ پیشنهادی ​

فهرست بازآرایی‌ها و تبدیل‌ها ​

فصل ۱۱ — تبدیل‌ها

Insert Data — درج داده

انگیزه (Motivation)

معاوضه‌های بالقوه (Potential Tradeoffs)

مکانیک به‌روزرسانی طرحواره (Schema Update Mechanics)

مکانیک مهاجرت داده (Data-Migration Mechanics)

مکانیک به‌روزرسانی برنامه‌های دسترسی (Access Program Update Mechanics)

Introduce New Column — معرفی ستون جدید

انگیزه (Motivation)

معاوضه‌های بالقوه (Potential Tradeoffs)

مکانیک به‌روزرسانی طرحواره (Schema Update Mechanics)

مکانیک مهاجرت داده (Data-Migration Mechanics)

مکانیک به‌روزرسانی برنامه‌های دسترسی (Access Program Update Mechanics)

Introduce New Table — معرفی جدول جدید

انگیزه (Motivation)

معاوضه‌های بالقوه (Potential Tradeoffs)

مکانیک به‌روزرسانی طرحواره (Schema Update Mechanics)

مکانیک مهاجرت داده (Data-Migration Mechanics)

مکانیک به‌روزرسانی برنامه‌های دسترسی (Access Program Update Mechanics)

Introduce View — معرفی نما

انگیزه (Motivation)

معاوضه‌های بالقوه (Potential Tradeoffs)

مکانیک به‌روزرسانی طرحواره (Schema Update Mechanics)

مکانیک مهاجرت داده (Data-Migration Mechanics)

مکانیک به‌روزرسانی برنامه‌های دسترسی (Access Program Update Mechanics)

Update Data — به‌روزرسانی داده

انگیزه (Motivation)

معاوضه‌های بالقوه (Potential Tradeoffs)

مکانیک به‌روزرسانی طرحواره (Schema Update Mechanics)

مکانیک مهاجرت داده (Data-Migration Mechanics)

مکانیک به‌روزرسانی برنامه‌های دسترسی (Access Program Update Mechanics)

پیوست. نمادگذاری مدل‌سازی داده UML

واژه‌نامه

منابع و مطالعهٔ پیشنهادی

فهرست بازآرایی‌ها و تبدیل‌ها