Bir sütun yeniden adlandırma işlemi otuz saniye sürüyor. Geçiş betiği bir dakikada tamamlanıyor. Test ortamına dağıtım hatasız gerçekleşiyor. Üretim ortamına dağıtım hatasız gerçekleşiyor. Üç saat sonra, bir Java servisinin hatalı yanıtlar döndürmesi, bir COBOL toplu işinin SQL hatasıyla sonlanması ve alt akış raporlama hattının kayıt yüklemeyi durdurması nedeniyle bir izleme uyarısı tetikleniyor. Sütun yeniden adlandırılmıştı. Uygulamalara kimse haber vermemişti.
Bu varsayımsal bir durum değil. Modern bilgi sistemleri, veritabanlarına bağlı çok çeşitli yazılım uygulamalarıyla çevrili veritabanlarından oluşmaktadır. Kurumsal uygulama entegrasyon ortamlarında, veritabanları farklı bağımsız taraflarca sağlanan uygulamalar tarafından paylaşılır ve bu uygulamaların geliştiricilerinin, veritabanı şemasının zaman içinde ne zaman ve nasıl geliştiği üzerinde genellikle çok az veya hiç kontrolü yoktur. Veritabanları ve yazılım uygulamaları her zaman senkronize kalmayabilir ve bu tutarsızlık veri kaybına, program hatalarına ve performans düşüşüne yol açar. Çözüm daha yavaş bir sürüm yayınlama süreci değildir. Çözüm, geçiş betiği çalıştırılmadan önce tam bir etki analizi yapmaktır.
Şema değişikliğinden önce tüm bağımlı bileşenleri tanıyın.
SMART TS XL Geçiş betiğiniz çalışmadan önce her uygulamayı, işlem hattını ve diller arası bağımlılığı haritalandırır.
DAHA FAZLASINI ÖĞRENİN…Tüm şema değişiklikleri eşit değildir.
Herhangi bir şema etki analizindeki ilk görev, önerilen değişikliği sınıflandırmaktır. Bir tabloya isteğe bağlı bir sütun ekleyen bir değişiklik, mevcut bir sütunu yeniden adlandıran bir değişiklikten temelde farklıdır, her ikisi de aynı ALTER TABLE sözdizimini içerse bile. Biri geriye dönük uyumludur; diğeri ise orijinal sütun adını referans alan her tüketici için sorun yaratır.
Yapıcı değişiklikler , tüketicinin herhangi bir işlem yapmasına gerek kalmadan mevcut tüketicilerde arızalara neden olur. Koordineli dağıtım gerektirirler; her bağımlı bileşen şema değişikliğinden önce veya eş zamanlı olarak güncellenmeli veya tüketici önce güncellenmeli ve şema güncellenene kadar bir uyumluluk katmanının arkasına dağıtılmalıdır.
Kırıcı olmayan değişiklikler geriye dönük uyumludur. Mevcut tüketiciler değişmeden çalışmaya devam eder. Yeni tüketiciler yeni şema öğesinden kendi hızlarında yararlanabilirler.
Sınıflandırma, analiz kapsamını, gerekli dağıtım koordinasyonunu ve geri alma karmaşıklığını belirler:
| Değişiklik Türü | Kırma | Birincil Etki Hedefi | Risk seviyesi |
|---|---|---|---|
| Boş değer alabilen sütun ekle | Yok hayır | Yalnızca yeni kod | Düşük |
| Varsayılan değer olmadan NOT NULL sütunu ekle | Evet | Tüm INSERT ifadeleri | Kritik |
| Sütunu yeniden adlandır | Evet | Bu kodu referans alan her SELECT, INSERT, UPDATE sorgusu | Kritik |
| Sütunu bırak | Evet | Herhangi bir yerdeki her referans | Kritik |
| Veri türünü genişlet (INT'den BIGINT'e) | Kısmi | Alan uzunluğunu veya türünü kontrol eden uygulamalar | Orta |
| Dar veri türü (VARCHAR 500 ila 100) | Evet | Yeni sınırdan daha uzun süre değer saklayan uygulamalar | Yüksek |
| Dizin ekle | Yok hayır | Sadece performansla ilgili, sorgular geçerliliğini koruyor. | Düşük |
| düşüş indeksi | Kısmi | Sorgu performansı; doğruluğu etkilenmez. | Orta |
| Tabloyu yeniden adlandır | Evet | Herhangi bir yerdeki her referans | Kritik |
| Yabancı anahtar kısıtlaması ekle | Kısmi | Mevcut veriler kısıtlamayı karşılamalıdır. | Orta Yüksek |
| nullable'ı NOT NULL olarak değiştirin. | Evet | Uygulamalar o sütuna NULL değeri ekliyor. | Yüksek |
| Saklı prosedür imzasını değiştir | Evet | İşlemi arayan tüm kişiler | Kritik |
| Saklı prosedürü bırak | Evet | İşlemi arayan tüm kişiler | Kritik |
| Görünümü yeniden adlandır | Evet | Bu manzarayı gören tüm tüketiciler | Kritik |
| Görünüm tanımını değiştir | Kısmi | Etkilenen sütunların tüketicileri | Orta Yüksek |
Dağıtım kuralı: Her kritik değişiklik, dağıtımdan önce eksiksiz bir bağımlı envanter gerektirir. Her yüksek riskli değişiklik, her aşamada doğrulama ile aşamalı bir dağıtım gerektirir. Her orta riskli değişiklik, en azından birincil etki hedeflerinin gözden geçirilmesini gerektirir. Düşük riskli değişiklikler standart testlerle dağıtılabilir, ancak yine de kayıt altına alınmalıdır.
Dört Bağımlılık Katmanı: Şema Etkisinin Bulunduğu Yerler
Şema değişikliği etki analizinde yapılan en önemli hata, onu yalnızca veritabanı sorunu olarak ele almaktır. Bir sütun adının değiştirilmesinin etkisi, veritabanının çok ötesine, her biri farklı analiz teknikleri gerektiren dört ayrı bağımlılık katmanına kadar uzanır.
Katman 1: Veritabanı İç Bağımlılıkları
En görünür katman. Veritabanının kendisinde, şema değişikliği şunları etkileyebilir:
Değiştirilen tablodan SELECT sorgusu yapan görünümler . SELECT listesine yeniden adlandırılan sütunu dahil eden bir görünüm, yeniden adlandırma işleminden sonra, görünümün somutlaştırılıp somutlaştırılmadığına bağlı olarak hata veya yanlış sonuçlar döndürecektir.
SELECT, INSERT, UPDATE veya DELETE ifadelerinde bu sütuna referans veren saklı prosedürler ve fonksiyonlar .
Tabloda değişiklik yapıldığında INSERT veya UPDATE işlemi gerçekleştiğinde tetiklenen ve mantıklarında belirli sütun adlarına referans veren tetikleyiciler .
Sütunu adıyla referans alan kısıtlamaları ve hesaplanmış sütunları kontrol edin .
Sütun silme işleminin geçersiz kılacağı yabancı anahtar ilişkileri .
Bu bağımlılıklar doğrudan veritabanı kataloğundan sorgulanabilir. SQL Server şunları sağlar: sys.sql_dependencies hem de sys.dm_sql_referenced_entitiesPostgreSQL şunları sağlar: pg_dependOracle, . ALL_DEPENDENCIESAşağıdaki sorgular, belirli bir tablo ve sütun için veritabanı içi bağımlılıkları listeler:
sql
-- SQL Server: all objects referencing a specific column
SELECT
OBJECT_NAME(d.object_id) AS dependent_object,
o.type_desc AS object_type,
OBJECT_NAME(d.referenced_major_id) AS referenced_table,
COL_NAME(d.referenced_major_id,
d.referenced_minor_id) AS referenced_column
FROM sys.sql_dependencies d
JOIN sys.objects o ON o.object_id = d.object_id
WHERE d.referenced_major_id = OBJECT_ID('dbo.Customers')
AND d.referenced_minor_id = COLUMNPROPERTY(
OBJECT_ID('dbo.Customers'), 'CustomerName', 'ColumnId')
ORDER BY o.type_desc, dependent_object;sql
-- PostgreSQL: views and functions depending on a specific column
SELECT
dep.classid::regclass AS dependency_type,
dependent.relname AS dependent_object,
a.attname AS referenced_column,
source.relname AS source_table
FROM pg_depend dep
JOIN pg_class source ON source.oid = dep.refobjid
JOIN pg_class dependent ON dependent.oid = dep.objid
JOIN pg_attribute a ON a.attrelid = dep.refobjid
AND a.attnum = dep.refobjsubid
WHERE source.relname = 'customers'
AND a.attname = 'customer_name';sql
-- Oracle: full dependency chain for objects referencing a table
SELECT
name AS dependent_object,
type AS object_type,
referenced_name,
referenced_type
FROM user_dependencies
WHERE referenced_name = 'CUSTOMERS'
ORDER BY type, name;Bu sorgular Katman 1'i tamamen kapsar. Katman 2'den 4'e kadar olan katmanlara dokunmazlar.
Katman 2: Uygulama Kodu Bağımlılıkları
İkinci katman, üretim olaylarının çoğunun kaynaklandığı ve veritabanı kataloğu sorgularının hiçbir görünürlük sağlamadığı yerdir. Veritabanıyla etkileşim kuran uygulama kodu şu yollarla etkileşim kurar:
Java ve .NET uygulamalarındaki JDBC ve ODBC sorgularında , sütun adları kaynak koduna gömülü SQL sorgularında dize sabitleri olarak görünür.
Hibernate, Entity Framework, SQLAlchemy ve ActiveRecord'da ORM eşlemeleri, tablo ve sütun adlarının nesne alanlarına eşlendiği yerlerdir. Bir sütun adının değiştirilmesi hem şema değişikliği hem de ORM yapılandırma değişikliği gerektirir ve yapılandırma değişikliği atlanırsa, ORM yeni sütun adını eski alana sessizce eşler ve bu da boş değerler veya eşleme hatalarına yol açar.
COBOL programlarında gömülü SQL , SQL'in COBOL PROCEDURE DIVISION kodundaki EXEC SQL / END-EXEC blokları içinde yer aldığı durumdur. Bu, kurumsal ortamlarda en kritik ve en sık gözden kaçırılan bağımlılık türüdür. İfade şu şekildedir:
COBOL
EXEC SQL
SELECT CUST-NAME, CUST-ADDR, CUST-PHONE
INTO :WS-CUST-NAME, :WS-CUST-ADDR, :WS-CUST-PHONE
FROM CUSTOMERS
WHERE CUST-ID = :WS-CUST-ID
END-EXECBu SQL değil, içine gömülü bir SQL ifadesi içeren COBOL kaynak kodudur. Standart bir SQL bağımlılık aracı veya veritabanı kataloğu sorgusu bu referansı bulamaz çünkü bu referans bir SQL nesne tanımında değil, bir COBOL kaynak dosyasında yer almaktadır. Bunu bulmak için COBOL kaynak kodunun ayrıştırılması gerekir.
Dinamik SQL, sütun adlarının çalışma zamanında oluşturulduğu dize şablonlarından oluşturulur. Bunlar, SQL değişmezlerinin statik analiziyle bulunamaz; ya dinamik analiz (uygulamanın test koşulları altında çalıştırılması) ya da dize oluşturma kalıplarının dikkatli manuel incelemesini gerektirir.
GraphQL çözümleyicileri ve API serileştiricileri Veritabanı sütun adlarını yanıt alanı adlarına eşleyen bir API. customerName adlı bir sütundan customer_name Doğrudan sütun eşlemesi, uygulama SQL sorgusu güncellense bile, sütun yeniden adlandırıldığında bozulacaktır, çünkü seri hale getirici eşlemesi orijinal adı da referans alır.
Katman 3: ETL, İşlem Hattı ve Veri Platformu Bağımlılıkları
Üçüncü katman, değiştirilen tablo veya sütuna dokunan her veri taşıma sürecini kapsar:
Değiştirilen tablodan veri seçip dönüştürme işlemini gerçekleştiren ve verileri alt sistemlere yükleyen ETL işleri (özel kodla yazılmış, Informatica, Talend veya SSIS tarafından yönetilen veya Airflow DAG'leri olarak ifade edilen işler).
Veri Değişikliği Yakalama (CDC) yapılandırmaları (Debezium, Oracle GoldenGate, SQL Server CDC), kaynak veritabanından satır düzeyindeki değişiklikleri aktarır. CDC yapılandırmaları belirli tablo ve sütun adlarına referans verir; bir sütun yeniden adlandırma işlemi, yeni sütun adıyla bir değişiklik olayı oluşturur ve bu olay, sonraki aşamalardaki CDC tüketicileri tarafından tanınmayabilir.
Veri ambarı ve veri gölü yükleme süreçleri, ilişkisel yapıları sütunlu formatlara dönüştürür. Kaynakta bir sütunun yeniden adlandırılması, veri ambarı şemasında, yükleme betiğinde ve sütuna referans veren her analitik sorguda veya gösterge panosunda da karşılık gelen bir yeniden adlandırmayı gerektirir.
BI araçlarına (Tableau çalışma kitapları, Power BI veri kümeleri, Looker LookML tanımları) yerleştirilmiş ve sütun adlarına doğrudan referans veren raporlama sorguları . Bunlar genellikle belgelenmemiş olup, ancak şema değişikliğinden sonra rapor çalışmayı durdurduğunda keşfedilir.
Katman 4: Aşağı Akış ve İş Ortağı Bağımlılıkları
En dış katman: Kuruluşun doğrudan kontrolü dışında olan ve değiştirilen veritabanından elde edilen verileri kullanan sistemler.
Harici API tüketicileri Sütun adlarından eşleştirilen alan adlarını içeren yanıtlar alan bir API. Eğer bir genel API şunları içeriyorsa: customer_name Yanıtında ve bu alan doğrudan sütun eşlemesiyle oluşturulduğunda, yeniden adlandırma işlemi her harici tüketici için API sözleşmesini bozar.
Değiştirilen tablodan düz dosya, CSV veya XML formatında veri özetleri alan iş ortağı veri akışları ; burada alan konumları veya adları özet şeması tarafından tanımlanır.
Düzenleyici rapor şartnamelerinde belirli sütun tanımlarına atıfta bulunulan ve harici bir otoriteyle mutabakat sağlanmış olabilecek uyumluluk ve düzenleyici raporlama sistemleri .
Uygulama Kodu Bağımlılıklarını Bulma: Analiz Teknikleri
Katman 1, katalog sorguları aracılığıyla kendi kendine hizmet sunar. Katman 2 ila 4, kullanılan dile ve mimariye bağlı olarak farklı teknikler gerektirir:
Dize araması (hızlı, eksik): Kod tabanında tablo adı, sütun adı veya her ikisi için grep veya ripgrep kullanın. Hızlı ve otomatikleştirmesi kolay. Dinamik olarak oluşturulan SQL'i gözden kaçırır ve yorumlarda ve belgelerde yanlış pozitif sonuçlar üretir.
darbe
# Find all files referencing a specific column
rg "customer_name|CUST-NAME|customerName" \
--type java --type py --type cs --type cbl \
--glob "!**/test/**" \
-l # list files only, for scope assessment
# More precise: find SQL contexts specifically
rg "(?i)(SELECT|INSERT|UPDATE|WHERE).*customer_name" \
--type java --type pyAST tabanlı analiz (daha hassas, dile özgü): Kaynak kodu soyut sözdizimi ağacına ayrıştırır ve SQL dize değişmezlerini, ORM ek açıklamalarını ve eşleme yapılandırmalarını bulmak için bu ağacı dolaşır. Dize aramasından daha doğrudur, ancak her dil için ayrı bir analizleyici gerektirir.
Semantik veri akışı analizi (en hassas, en pahalı): Bir uygulamanın yapabileceği tüm olası veritabanı etkileşimlerini çıkarmak için veri akışı analizini kullanan statik program analizi. IEEE'nin şema değişikliği etki analizi üzerine yaptığı araştırmada resmileştirilen bu teknik, veritabanı sorgusu oluşturulmasından değişken atamalarına ve yürütme noktasına kadar verileri izler ve SQL sütun referanslarını, tam metinler olarak yazılmak yerine parçalardan bir araya getirilmiş olsalar bile tanımlar. Araştırma, bu analizin yüksek hassasiyet elde etmek için bağlama duyarlı olması gerektiğini ve program dilimlemenin eksiksizliği korurken analiz süresini önemli ölçüde azalttığını göstermektedir.
Pratik öneri: Kapsam değerlendirmesini hızlandırmak için dize araması kullanın. Kritik değişikliklerden önce yetkili numaralandırma için AST veya anlamsal analiz kullanın. Yalnızca dize aramasına dayalı olarak sütun yeniden adlandırma veya sütun silme işlemi asla gerçekleştirmeyin, yanlış negatif riski çok yüksektir.
Çok Dilli Kurumsal Ortamlarda Şema Etkisi
Standart modern bir web uygulamasında (Java arka uç, React ön uç, PostgreSQL veritabanı), şema değişikliğinin bağımlılık kapsamı uygulamanın kaynak koduyla sınırlıdır. Bir sütun yeniden adlandırması, Java katmanındaki SQL dizelerini ve seri hale getiricideki API alan eşlemesini etkiler. Her ikisi de aynı kod tabanında arama yapılarak bulunabilir.
Eski ana bilgisayar sistemlerine sahip kurumsal ortamlar her açıdan farklılık gösterir. Bir finans kurumunun temel bankacılık sistemindeki bir DB2 sütununa şu şekillerde referans verilebilir:
- Günlük hesap işlemlerini işleyen, içine SQL yerleştirilmiş COBOL programları.
- Düzeni sütuna karşılık gelen ayıklama dosyaları oluşturan JCL iş adımları
- Sütuna referans veren saklı prosedürleri çağıran Java mikroservisleri
- Raporlama için JDBC aracılığıyla doğrudan DB2'yi sorgulayan Python veri işlem hatları.
- İş zekası araçlarının yönetici panoları için kullandığı SQL görünümleri
- Terminal ekranlarında sütun değerini görüntüleyen CICS işlem programları.
Bu referanslar beş farklı dilde, üç farklı çalışma ortamında (ana bilgisayar, bulut, BI platformu) bulunur ve birbirleriyle asla doğrudan iletişim kurmayabilecek ekipler tarafından yönetilir. Veritabanı ekibi ve Java servis ekibi arasında kararlaştırılan bir sütun yeniden adlandırması, sistemleri arızalanana kadar COBOL ekibi, raporlama ekibi ve BI ekibi tarafından bilinmeyebilir.
Statik program analizi teknikleri, veri akışı analizini kullanarak olası tüm veritabanı etkileşimlerini çıkararak, ilişkisel veritabanı şema değişikliklerinin nesne yönelimli uygulamalar üzerindeki etkisini belirler. Aynı prensip, COBOL, JCL, Python ve SQL'e eş zamanlı olarak genişletildiğinde, COBOL kaynak kodundaki gömülü SQL'i, JCL programlarındaki EXEC SQL bloklarını, Python betiklerindeki parametreli sorguları ve veritabanındaki SQL nesnelerini ayrıştırarak, çok dilli şema değişikliği etki analizini yönetilebilir hale getiren eksiksiz bir diller arası bağımlılık haritası oluşturur.
CI/CD Entegrasyonu: Etki Analizini Otomatik Hale Getirmek
Her şema değişikliğinden önce manuel etki analizi yapmak, hiç analiz yapmamaktan daha iyidir. CI/CD kontrol noktası olarak otomatik etki analizi, manuel analizden daha iyidir; her seferinde çalışır, geliştirici disiplinine bağlı kalmaz ve analiz tamamlanmadığında dağıtımı engeller.
tatlım
# GitHub Actions: schema impact gate
name: Schema Change Impact Analysis
on:
pull_request:
paths:
- 'migrations/**'
- 'schema/**'
- '**/*.sql'
jobs:
schema-impact:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Detect schema changes
id: detect
run: |
git diff origin/main...HEAD -- migrations/ schema/ \
> schema_changes.diff
# Classify: any breaking changes?
if grep -qiE \
"DROP COLUMN|RENAME|ALTER.*NOT NULL|DROP TABLE|DROP PROCEDURE" \
schema_changes.diff; then
echo "breaking=true" >> $GITHUB_OUTPUT
echo "Breaking schema changes detected"
else
echo "breaking=false" >> $GITHUB_OUTPUT
fi
- name: Block on breaking change without impact sign-off
if: steps.detect.outputs.breaking == 'true'
run: |
# Check for required impact analysis label on PR
if ! gh pr view ${{ github.event.pull_request.number }} \
--json labels --jq '.labels[].name' \
| grep -q "impact-analysis-complete"; then
echo "ERROR: Breaking schema change requires impact-analysis-complete label"
echo "Complete the impact analysis checklist before merging"
exit 1
fi
env:
GH_TOKEN: ${{ github.token }}
- name: Run catalog dependency check
run: |
psql ${{ secrets.DB_URL }} -f scripts/check_dependencies.sql \
| tee dependency_report.txt
if grep -q "DEPENDENT_COUNT > 0" dependency_report.txt; then
echo "Dependents found -- review dependency_report.txt"
fiYukarıdaki kontrol noktası üç şey yapar: herhangi bir kırıcı değişiklik modelinin olup olmadığını tespit eder, birleştirme işlemine izin verilmeden önce bir gözden geçirenin etki analizini tamamlayıp etiketlemesini gerektirir ve veritabanı içi bağımlılıkları listelemek için katalog bağımlılık sorgusunu çalıştırır. Etiket gereksinimi, temel insan kontrol noktasıdır, işlem hattı tarafından atlanamaz; bu da kodun birleştirilebilmesi için etki analizinin yapılması ve belgelenmesi gerektiği anlamına gelir.
Tam bir Şema Etki Raporu Neler İçerir?
Şema etki analizinin çıktısı, değişiklik danışma kurullarının, mimarların ve veritabanı yöneticilerinin dağıtımı onaylamak için kullanabileceği yapılandırılmış bir rapordur. Tam bir rapor şunları içerir:
1. Önerilen değişiklik tanımı , uygulanacak tam DDL ifadesi, etkilenen tablo ve sütun ve değişikliğin nedeni.
2. Risk taksonomisinden sınıflandırma değişikliği: kırılma veya kırılmama, risk düzeyi ve belirli etki kategorisi (veri kaybı riski, sorgu hatası riski, performans riski).
3. Veritabanı içi bağımlılıklar , katalog sorgusunun çıktısı: Değiştirilen nesneye referans veren her görünüm, saklı prosedür, fonksiyon ve tetikleyici, mevcut tanımı ve gerekli değişiklik ile birlikte.
4. Uygulama koduna bağlı dosyalar , dile göre, dosya yolu, mümkünse satır numarası ve bulunan belirli SQL referansı ile birlikte. Kod tabanının birden fazla ekip tarafından yönetilmesi durumunda, ekip veya hizmete göre düzenlenir.
5. ETL ve işlem hattına bağlı öğeler , işlem hattı adına, göreve ve değiştirilen sütun veya tabloya yapılan özel referansa göre.
6. Sistem adına, veri akışına veya API sözleşmesine göre, alt kademe ve iş ortağına bağlı bileşenler ; alan adı, alt kademe arayüzünde göründüğü şekilde belirtilir.
7. Bağımlılık başına gerekli değişiklikler : Bulunan her bağımlılık için, şema değişikliği uygulandıktan sonra doğruluğu korumak için gereken belirli değişiklik.
8. Dağıtım sırası , tutarlılığı korumak için bağımlı öğelerin güncellenmesi ve şema değişikliğinin dağıtılması gereken sıradır. Kırıcı değişiklikler genellikle şunları gerektirir: (1) uyumluluk katmanını veya varsayılan değeri dağıtın, (2) tüm uygulama kodunu yeni sütun adına referans verecek şekilde güncelleyin, (3) uygulama kodunu dağıtın, (4) doğrulayın, (5) şema değişikliğini dağıtın, (6) doğrulayın, (7) uyumluluk katmanını kaldırın.
9. Gerekli test senaryoları : Bağımlı tür başına bir doğrulama testi ve değiştirilen saklı prosedürler için regresyon testleri.
10. Geri alma planı , ters DDL ve dağıtımın geri alınması gerekiyorsa önceki şema durumunu geri yüklemek için gereken veri geçişi.
Raporlama disiplini: Var olan ancak üzerinde işlem yapılmayan bir etki raporu, hiç rapor olmamasından daha kötüdür; gerçek risk azaltılmamışken, gerekli özenin gösterildiği izlenimini verir. Bağımlı listedeki her madde, devreye alınmadan önce güncellenmeli veya bir acil durum planıyla birlikte bilinen bir risk olarak açıkça kabul edilmelidir.
Ne kadar SMART TS XL Diller Arası Şema Etki Analizi Sunar
Standart veritabanı kataloğu sorguları, veritabanı içindeki Katman 1 bağımlılıklarını, görünümleri, saklı prosedürleri ve tetikleyicileri listeler. Uygulama kodu arama araçları, tek bir dil içindeki bazı Katman 2 bağımlılıklarını listeler. Hiçbir tek araç, tüm dillerde dört katmanın tamamını kapsamaz.
SMART TS XL'S statik kod analizi COBOL kaynak dosyalarındaki gömülü SQL'i, Java servislerindeki JDBC sorgu dizelerini, Python işlem hatlarındaki SQLAlchemy modellerini ve SQL nesne tanımlarını aynı anda ayrıştırır. Bir DB2 sütununun yeniden adlandırılması önerildiğinde, SMART TS XL Bu analiz işleminde, çok dilli portföyün tamamında, o sütuna referans veren her COBOL EXEC SQL bloğunu, sütun adını içeren her Java JDBC sorgu dizesini, sütunu kullanan her Python sorgusunu ve ona referans veren her SQL görünümünü veya saklı prosedürünü tanımlar.
Uygulama bağımlılık eşlemesi, analizi doğrudan sütun referanslarının ötesine, yapısal bağımlılık zincirine kadar genişletir: eğer bir Java servisi, değiştirilen sütuna referans veren bir saklı prosedürü çağırıyorsa, bağımlılık haritası hem Java-prosedür bağımlılığını hem de prosedür-sütun bağımlılığını temsil eder; bu da Java servisinin kodunda doğrudan sütun referansı olmasa bile etki kapsamı içinde görünür olmasını sağlar.
Etki analizi özelliği, her şema değişikliğinden önce gelen şu özel soruyu yanıtlamak için bu diller arası bağımlılık grafiğini kullanır: Önerilen bu değişiklik göz önüne alındığında, her dilde ve her katmanda etkilenecek her bileşeni listeleyin. Yanıt, yukarıdaki etki raporu şablonuna doğrudan eşleşen yapılandırılmış, numaralandırılmış bir listedir; bir tahmin değil, bir geliştiricinin etkilenebilecekler hakkındaki en iyi hatırlayışı değil, gerçek koddan yapısal bir türetmedir.
Kurumsal arama özelliği, bağımlılık envanterinin değişiklik yönetimi yaşam döngüsü boyunca sorgulanabilir olmasını sağlar: COBOL, Java, Python ve SQL'de belirli bir sütuna referans veren her programı aynı anda, saniyeler içinde, milyonlarca satır kod arasında bulun.
Çeşitli ortamlarda şema değişikliklerini yöneten ekipler için miras modernizasyonu Veritabanının, modernize edilen bir COBOL ana bilgisayar uygulaması ile onu değiştiren modern Java servisleri arasında paylaşıldığı programlarda, diller arası etki analizi isteğe bağlı değildir. Modernizasyon geçişi sırasında, hem eski hem de modern katmanlar aynı anda üretimdedir. Java servisinin bakış açısından güvenli olan bir şema değişikliği, onunla birlikte çalışan COBOL programları için bilinmeyebilir. SMART TS XL O sınırın her iki tarafını da aynı anda görüyor.
Şema değişiklikleri uygulamaları bozmaz. Analiz edilmemiş şema değişiklikleri bozar.
Bu kılavuzun başındaki dağıtım hatası, yani bir Java servisini, bir COBOL toplu işini ve bir raporlama hattını canlıya geçtikten üç saat sonra bozan sütun yeniden adlandırma hatası, geçiş betiğinde hiçbir sorun yoktu. Betik doğru şekilde çalıştı. Sütun tam olarak amaçlandığı gibi yeniden adlandırıldı. Başarısız olan, ondan önce yapılması gereken analizdi: orijinal sütun adını referans alan her uygulamanın listelenmesi, her birinin güncellendiğinin doğrulanması ve dağıtım sırasının veritabanı ile her tüketici arasında tutarlılığı koruduğunun doğrulanması.
Şema etki analizi bürokratik bir kontrol noktası değildir. Riskli bir dağıtımı güvenli bir dağıtıma dönüştüren, bir değişikliğin bilinmeyen kapsamını, etkilenecek her şeyin numaralandırılmış, doğrulanabilir bir listesine dönüştüren bir çalışmadır. Geçiş betiği bir dakika sürer. Etki analizi gerektiği kadar sürer. Önlediği üretim olayı ise günler sürer.
