Veeru ümbernimetamine võtab kolmkümmend sekundit. Migratsiooniskript kirjutab minutiga. Juurutamine testimiskeskkonda kulgeb veatult. Juurutamine tootmiskeskkonda kulgeb veatult. Kolm tundi hiljem käivitub jälgimishoiatus, kuna Java teenus tagastab vigaseid vastuseid, COBOL-paketttöö katkestab töö SQL-veaga ja allavoolu aruandluskanal on lõpetanud kirjete laadimise. Veerg nimetati ümber. Rakendusi ei teavitatud sellest keegi.
See ei ole hüpoteetiline. Kaasaegsed infosüsteemid koosnevad andmebaasidest, mida ümbritseb suur hulk tarkvararakendusi, olenevalt andmebaasidest. Ettevõtte rakenduste integratsioonikeskkondades jagavad andmebaase erinevate sõltumatute osapoolte loodud rakendused ning nende rakenduste arendajatel on sageli vähe või üldse mitte kontrolli selle üle, millal ja kuidas andmebaasi skeem aja jooksul areneb. Andmebaasid ja tarkvararakendused ei pruugi alati sünkroonis püsida ning see ebajärjekindlus põhjustab andmete kadu, programmi rikkeid ja jõudluse vähenemist. Lahendus ei ole aeglasem väljalaskeprotsess. See on täielik mõjuanalüüs enne migratsiooniskripti käivitamist.
Enne skeemi muutmist teadke iga ülalpeetavat
SMART TS XL kaardistab iga rakenduse, torujuhtme ja keeltevahelise sõltuvuse enne migreerimisskripti käivitamist.
SAAGE LISATEAVET…Kõik skeemimuudatused ei ole võrdsed
Skeemi mõju analüüsi esimene ülesanne on kavandatava muudatuse klassifitseerimine. Muudatus, mis lisab tabelisse valikulise veeru, erineb põhimõtteliselt muudatusest, mis nimetab ümber olemasoleva veeru, isegi kui mõlemad hõlmavad sama ALTER TABLE süntaksit. Üks on tagasiühilduv; teine on katki iga tarbija jaoks, kes viitab algsele veerunimele.
Katkestavad muudatused põhjustavad olemasolevates tarbijates tõrkeid ilma tarbijapoolse sekkumiseta. Need nõuavad koordineeritud juurutamist, iga sõltuvat üksust tuleb värskendada enne skeemi muutmist või samaaegselt sellega või tuleb tarbijat kõigepealt värskendada ja juurutada ühilduvuskihi taha, kuni skeem järele jõuab.
Mittekatkestavad muudatused on tagasiühilduvad. Olemasolevad tarbijad jätkavad toimimist muutmata kujul. Uued tarbijad saavad uut skeemielementi omas tempos ära kasutada.
Klassifikatsioon määrab analüüsi ulatuse, vajaliku juurutamise koordineerimise ja tagasipööramise keerukuse:
| Muuda tüüpi | Purustamine | Peamine mõju sihtmärk | Riskitase |
|---|---|---|---|
| Lisa nullitav veerg | Ei | Ainult uus kood | Madal |
| Lisa NOT NULL veerg ilma vaikeväärtuseta | Jah | Kõik INSERT-laused | Kriitiline |
| Nimeta veerg ümber | Jah | Iga sellele viitav SELECT, INSERT ja UPDATE käsk | Kriitiline |
| Langetage veerg | Jah | Iga viide kõikjal | Kriitiline |
| Laienda andmetüüpi (INT-st BIGINT-iks) | Osaline | Rakendused, mis kontrollivad välja pikkust või tüüpi | Keskmine |
| Kitsas andmetüüp (VARCHAR 500 kuni 100) | Jah | Rakendused, mis salvestavad väärtusi uuest limiidist kauem | Kõrge |
| Lisa indeks | Ei | Ainult jõudlus, päringud jäävad kehtivaks | Madal |
| Langetamise indeks | Osaline | Päringu jõudlus; korrektsus ei muutu | Keskmine |
| Nimeta tabel ümber | Jah | Iga viide kõikjal | Kriitiline |
| Lisa võõrvõtme piirang | Osaline | Olemasolevad andmed peavad vastama piirangule | Keskmisel kõrgusel |
| Muuda nullitav väärtuseks NOT NULL | Jah | Rakendused, mis lisavad sellesse veergu NULL-i | Kõrge |
| Salvestatud protseduuri allkirja muutmine | Jah | Kõik protseduuri kutsujad | Kriitiline |
| Salvestatud protseduuri kustutamine | Jah | Kõik protseduuri kutsujad | Kriitiline |
| Vaate ümbernimetamine | Jah | Kõik vaate tarbijad | Kriitiline |
| Vaate definitsiooni muutmine | Osaline | Mõjutatud veergude tarbijad | Keskmisel kõrgusel |
Juurutamise reegel: iga kriitilise muudatuse puhul on enne juurutamist vaja teha täielik sõltuvate osapoolte inventuur. Iga kõrge riskiga muudatuse puhul on vaja etapiviisilist juurutamist koos iga etapi valideerimisega. Iga keskmise riskiga muudatuse puhul on vaja vähemalt üle vaadata peamised mõjusihtmärgid. Madala riskiga muudatusi saab juurutada standardse testimisega, kuid need tuleks siiski logida.
Neli sõltuvuskihti: kus skeemi mõju avaldub
Skeemimuudatuste mõju analüüsi kõige olulisem viga on selle käsitlemine ainult andmebaasi probleemina. Veeru ümbernimetamise mõju ulatub andmebaasist endast kaugemale, läbi nelja erineva sõltuvuskihi, millest igaühe loetlemiseks on vaja erinevaid analüüsitehnikaid.
1. kiht: andmebaasi sisemised sõltuvused
Kõige nähtavam kiht. Andmebaasis endas võib skeemi muutmine mõjutada järgmist:
Vaated, mis teostavad muudetud tabelist SELECT-käsu. Vaade, mille SELECT-loend sisaldab ümbernimetatud veergu, tagastab pärast ümbernimetamist vea või valed tulemused, olenevalt sellest, kas vaade materialiseerub.
Salvestatud protseduurid ja funktsioonid , mis viitavad veerule oma SELECT-, INSERT-, UPDATE- või DELETE-lausetes.
Päästikud , mis käivituvad muudetud tabeli INSERT või UPDATE korral ja viitavad oma loogikas konkreetsetele veerunimedele.
Kontrollige piiranguid ja arvutatud veerge , mis viitavad veerule nime järgi.
Välisvõtme seosed , mille veeru eemaldamine kehtetuks muudaks.
Neid sõltuvusi saab otse andmebaasi kataloogist päringuga kontrollida. SQL Server pakub sys.sql_dependencies ja sys.dm_sql_referenced_entitiesPostgreSQL pakub pg_dependOracle pakub ALL_DEPENDENCIESAllolevad päringud loetlevad andmebaasisiseseid sõltuvaid elemente konkreetse tabeli ja veeru jaoks:
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;Need päringud katavad täielikult 1. kihi. Need ei puuduta 2. kuni 4. kihte.
2. kiht: rakenduskoodi sõltuvused
Teine kiht on koht, kust enamik tootmisintsidente pärineb ja kus andmebaasi kataloogipäringud ei paku mingit nähtavust. Rakenduskood, mis andmebaasiga suhtleb, teeb seda järgmiselt:
JDBC ja ODBC päringud Java ja .NET rakendustes, kus veerunimed kuvatakse lähtekoodi manustatud SQL-päringutes string-literaalidena.
ORM-kaardistused Hibernate'is, Entity Frameworkis, SQLAlchemys ja ActiveRecordis, kus tabeli ja veeru nimed kaardistatakse objektiväljadega. Veeru ümbernimetamine nõuab nii skeemi muutmist kui ka ORM-i konfiguratsiooni muutmist ning kui konfiguratsiooni muutmine jääb märkamata, kaardistab ORM uue veeru nime märkamatult vana väljaga, tekitades tühiväärtusi või kaardistusvigu.
COBOL-programmidesse manustatud SQL , kus SQL esineb COBOL PROCEDURE DIVISION koodis EXEC SQL / END-EXEC plokkides. See on ettevõttekeskkondades kõige olulisem ja kõige sagedamini tähelepanuta jäetud sõltuvustüüp. Väide:
kobol
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-EXECei ole SQL, vaid COBOL-i lähtekood, mis sisaldab manustatud SQL-lauset. Standardne SQL-i sõltuvustööriist või andmebaasi kataloogipäring seda viidet ei leia, kuna see asub COBOL-i lähtekoodifailis, mitte SQL-objekti definitsioonis. Selle leidmiseks on vaja COBOL-i lähtekoodi parsida.
Dünaamiline SQL, mis on loodud stringimallidest, kus veerunimed pannakse käitusajal kokku. Neid ei saa SQL-literaalide staatilise analüüsi abil leida, need nõuavad kas dünaamilist analüüsi (rakenduse käivitamine testimistingimustes) või stringi konstruktsioonimustrite hoolikat käsitsi ülevaatamist.
GraphQL resolverid ja API serialiseerijad mis seovad andmebaasi veerunimed vastuseväljade nimedega. API, mis avaldab customerName veerust nimega customer_name Otsese veerukaardistuse kaudu toimimine katkeb veeru ümbernimetamisel isegi siis, kui rakenduse SQL-päringut värskendatakse, kuna serialiseerija kaardistus viitab ka algsele nimele.
3. kiht: ETL-i, torujuhtme ja andmeplatvormi sõltuvused
Kolmas kiht hõlmab kõiki andmete liikumise protsesse, mis puudutavad muudetud tabelit või veergu:
ETL-tööd (olenemata sellest, kas need on kirjutatud kohandatud koodis, hallatavad Informatica, Talendi või SSIS-i poolt või väljendatud Airflow DAG-idena), mis VALIVAD muudetud tabelist teisendamiseks ja laadimiseks allavoolu süsteemidesse.
Muudatuste andmete kogumise (CDC) konfiguratsioonid (Debezium, Oracle GoldenGate, SQL Server CDC), mis voogesitavad rea tasemel muudatusi lähteandmebaasist. CDC konfiguratsioonid viitavad konkreetsetele tabeli- ja veerunimedele, veeru ümbernimetamine loob muutmissündmuse uue veerunimega, mida allavoolu CDC tarbijad ei pruugi ära tunda.
Andmeladu ja andmejärv laadivad protsesse , mis tasandavad relatsioonistruktuurid veergude kaupa. Veeru ümbernimetamine allikal nõuab vastavat ümbernimetamist andmeladu skeemis, laadimisskriptis ja igas analüütilises päringus või armatuurlaual, mis veerule viitab.
BI-tööriistadesse (Tableau töövihikud, Power BI andmestikud, Looker LookML definitsioonid) manustatud aruandluspäringud , mis viitavad otse veerunimedele. Need on sageli dokumenteerimata ja avastatakse alles siis, kui aruanne pärast skeemi muutmist enam ei tööta.
4. kiht: allavoolu ja partneri sõltuvused
Kõige välimine kiht: süsteemid, mis on väljaspool organisatsiooni otsest kontrolli ja tarbivad muudetud andmebaasist saadud andmeid.
Välised API tarbijad mis saavad vastuseid, mis sisaldavad veerunimedega vastendatud väljanimesid. Kui avalik API sisaldab customer_name oma vastuses ja see väli on loodud otsese veerukaardistamise teel, siis ümbernimetamine rikub API lepingu iga välise tarbija jaoks.
Partneri andmevood , mis saavad muudetud tabelist väljavõtteid lamefaili, CSV- või XML-vormingus, kus väljade asukohad või nimed on määratletud väljavõtte skeemiga.
Vastavus- ja regulatiivse aruandluse süsteemid, mille puhul regulatiivsete aruannete spetsifikatsioonides viidatakse konkreetsetele veergude määratlustele, mis võivad olla kokku lepitud välise asutusega.
Rakenduskoodi sõltuvuste leidmine: analüüsitehnikad
1. kiht on iseteeninduslik kataloogipäringute kaudu. 2. kuni 4. kiht vajavad erinevaid tehnikaid, olenevalt keelest ja arhitektuurist:
Stringiotsing (kiire, mittetäielik): Grep või ripgrep kogu koodibaasis tabeli nime, veeru nime või mõlema leidmiseks. Kiire ja lihtne automatiseerida. Ebaõnnestub dünaamiliselt loodud SQL-is ja annab kommentaarides ja dokumentatsioonis valepositiivseid tulemusi.
sisse lööma
# 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-põhine analüüs (täpsemalt, keelepõhine): parsib lähtekoodi abstraktseks süntaksipuuks ja läbib selle, et leida SQL-stringi literaale, ORM-annotatsioone ja kaardistuskonfiguratsioone. Täpsem kui stringiotsing, kuid nõuab iga keele jaoks eraldi analüsaatorit.
Semantiline andmevoo analüüs (kõige täpsem, kõige kallim): staatiline programmianalüüs, mis kasutab andmevoo analüüsi, et eraldada kõik võimalikud andmebaasi interaktsioonid, mida rakendus võib teha. See tehnika, mis on formaliseeritud IEEE uuringus skeemimuutuste mõju analüüsi kohta, jälgib andmeid andmebaasi päringu koostamisest muutujate omistamise kaudu kuni teostuspunktini, tuvastades SQL-veeru viited isegi siis, kui need on kokku pandud osadest, mitte kirjutatud täielike literaalidena. Uuring näitab, et see analüüs peab olema kontekstitundlik, et saavutada kõrge täpsus, ja et programmi viilutamine vähendab analüüsiaega oluliselt, säilitades samal ajal terviklikkuse.
Praktiline soovitus: ulatuse kiireks hindamiseks kasutage stringiotsingut. Enne kriitilisi muudatusi kasutage autoriteetseks loendamiseks AST-d või semantilist analüüsi. Ärge kunagi kasutage veeru ümbernimetamist ega veeru eemaldamist ainult stringiotsingu põhjal, vale-negatiivsete tulemuste risk on liiga suur.
Skeemi mõju mitmekeelsetes ettevõttekeskkondades
Standardses tänapäevases veebirakenduses, Java-taustaprogrammis, Reacti esiotsas ja PostgreSQL-i andmebaasis on skeemimuudatuse sõltuvusulatus piiratud rakenduse lähtekoodiga. Veeru ümbernimetamine mõjutab Java-kihi SQL-stringe ja serialiseerija API-väljade vastendust. Mõlemad on leitavad samast koodibaasist otsides.
Ettevõtte keskkonnad, kus kasutatakse pärandpõhiseid suurarvutisüsteeme, on igas mõttes erinevad. Finantsasutuse põhipangandussüsteemi DB2 veerule võib viidata järgmiselt:
- COBOL-programmid sisseehitatud SQL-iga, mis töötlevad igapäevaseid kontotehinguid
- JCL-töö etapid, mis genereerivad ekstraktimisfaile, mille paigutus vastab veerule
- Java mikroteenused, mis kutsuvad veerule viitavaid salvestatud protseduure
- Pythoni andmekanalid, mis pärivad aruandluse jaoks otse JDBC kaudu DB2-le
- BI-tööriistade juhtimispaneelide SQL-vaated
- CICS-i tehinguprogrammid, mis kuvavad veeru väärtust terminaliekraanidel
Need viited eksisteerivad viies erinevas keeles, kolmes erinevas käituskeskkonnas (suurarvuti, pilv, BI-platvorm) ning neid haldavad meeskonnad, kes ei pruugi kunagi otse suhelda. Andmebaasimeeskonna ja Java teenindusmeeskonna vahel kokkulepitud veeru ümbernimetamine võib olla COBOL-meeskonnale, aruandlusmeeskonnale ja BI-meeskonnale teadmata enne, kui nende süsteemid rikki lähevad.
Staatilise programmi analüüsi tehnikad tuvastavad relatsioonandmebaasi skeemi muudatuste mõju objektorienteeritud rakendustele, kasutades andmevoo analüüsi, et eraldada kõik võimalikud andmebaasi interaktsioonid. Sama põhimõtet laiendatakse samaaegselt COBOL-ile, JCL-ile, Pythoni ja SQL-ile, parsides COBOL-i lähtekoodi manustatud SQL-i, JCL-programmide EXEC SQL-plokke, Pythoni skriptide parameetriga päringuid ja andmebaasi SQL-objekte, luues täieliku keelteülese sõltuvuskaardi, mis muudab mitmekeelse skeemi muudatuste mõju analüüsi lihtsaks.
CI/CD integratsioon: mõjuanalüüsi automatiseerimine
Manuaalne mõjuanalüüs enne iga skeemimuudatust on parem kui analüüsi puudumine. Automatiseeritud mõjuanalüüs CI/CD väravana on parem kui käsitsi analüüs, see töötab iga kord, ilma arendaja distsipliinile toetumata, ja blokeerib juurutamise, kui analüüs on poolik.
yaml
# 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"
fiÜlaltoodud värav teeb kolme asja: tuvastab, kas esineb murrangulisi muutusmustreid, nõuab enne ühendamise lubamist, et ülevaataja oleks mõjuanalüüsi lõpetanud ja sildistanud, ning käivitab kataloogi sõltuvuspäringu andmebaasi sisemiste sõltuvuste loetlemiseks. Sildistamise nõue on peamine inimlik kontrollpunkt, mida torujuhe ei saa mööda hiilida, mis tähendab, et mõjuanalüüs peab toimuma ja dokumenteeritama enne koodi ühendamist.
Täieliku skeemi mõjuaruande sisu
Skeemi mõjuanalüüsi väljundiks on struktureeritud aruanne, mida muudatuste nõuandekogud, arhitektid ja andmebaasiadministraatorid saavad kasutada juurutamise autoriseerimiseks. Täielik aruanne sisaldab järgmist:
1. Kavandatud muudatuse definitsioon , täpne juurutatav DDL-lause, mõjutatud tabel ja veerg ning muudatuse põhjus.
2. Muudatuste klassifikatsioon riski taksonoomia alusel: murdev või mittemurdev, riskitase ja konkreetne mõjukategooria (andmete kadumise risk, päringu tõrke risk, jõudlusrisk).
3. Andmebaasi-sisesed sõltuvad elemendid , kataloogipäringu väljund: iga vaade, salvestatud protseduur, funktsioon ja päästik, mis viitab muudetud objektile koos selle praeguse definitsiooni ja vajaliku muudatusega.
4. Rakenduskoodist sõltuvad üksused keele kaupa koos failitee, võimaluse korral reanumbri ja leitud konkreetse SQL-viitega. Järjestatud meeskonna või teenuse kaupa, kui koodibaasi haldab mitu meeskonda.
5. ETL-i ja torujuhtme sõltuvad üksused torujuhtme nime, ülesande ja muudetud veeru või tabeli konkreetse viite järgi.
6. Allavoolu ja partneri ülalpeetavad üksused süsteemi nime, andmevoo või API lepingu järgi, kusjuures väljanimi kuvatakse allavoolu liideses.
7. Nõutavad muudatused iga ülalpeetava kohta , iga leitud ülalpeetava kohta konkreetne muudatus, mis on vajalik õigsuse säilitamiseks pärast skeemimuudatuse juurutamist.
8. Juurutamise järjekord ehk järjekord, milles sõltuvaid elemente tuleb värskendada ja skeemimuudatust järjepidevuse säilitamiseks juurutada. Kahtluse korral tuleb tavaliselt teha järgmist: (1) ühilduvuskihi või vaikeväärtuse juurutamine, (2) kogu rakenduskoodi värskendamine uue veerunime viitamiseks, (3) rakenduskoodi juurutamine, (4) valideerimine, (5) skeemimuudatuse juurutamine, (6) valideerimine, (7) ühilduvuskihi eemaldamine.
9. Nõutavad testijuhtumid , üks valideerimistest iga sõltuva tüübi kohta, lisaks regressioonitestid kõigi muudetud salvestatud protseduuride jaoks.
10. Tagasipöördumisplaan , pöörd-DDL ja mis tahes andmete migratsioon, mis on vajalik eelmise skeemi oleku taastamiseks, kui juurutamine tuleb tagasi pöörata.
Aruande distsipliin: mõjuaruanne, mis on olemas, kuid mille alusel ei tegutseta, on halvem kui aruande puudumine – see jätab mulje hoolsuskohustusest, samas kui tegelikku riski ei leevendata. Iga sõltuva nimekirja üksust tuleb enne kasutuselevõttu ajakohastada või selgesõnaliselt aktsepteerida teadaoleva riskina koos varuplaaniga.
Kuidas SMART TS XL Pakub keelteülese skeemi mõjuanalüüsi
Standardsed andmebaasi kataloogipäringud loetlevad 1. kihi sõltuvad üksused, andmebaasis olevad vaated, salvestatud protseduurid ja päästikud. Rakenduskoodi otsingutööriistad loetlevad mõned 2. kihi sõltuvad üksused ühe keele piires. Ükski tööriist ei kata kõiki nelja kihti kõigis keeltes.
SMART TS XL'S staatilise koodi analüüs parsib samaaegselt COBOL-i lähtekoodifailidesse manustatud SQL-i, Java-teenuste JDBC päringustringidesse, Pythoni torujuhtmete SQLAlchemy mudelitesse ja SQL-objektide definitsioonidesse manustatud SQL-i. Kui DB2 veergu pakutakse ümbernimetamiseks, SMART TS XL identifitseerib ühe analüüsi käigus kogu mitmekeelses portfoolios iga COBOL EXEC SQL-ploki, mis sellele veerule viitab, iga Java JDBC päringustringi, mis sisaldab veeru nime, iga Pythoni päringu, mis seda veergu kasutab, ja iga SQL-vaate või salvestatud protseduuri, mis sellele viitab.
Rakenduse sõltuvuste kaardistamine laiendab analüüsi otsestest veeruviidetest kaugemale struktuurse sõltuvusahelani: kui Java teenus kutsub salvestatud protseduuri, mis viitab muudetud veerule, esindab sõltuvuste kaart nii Java ja protseduuri vahelist sõltuvust kui ka protseduuri ja veeru vahelist sõltuvust, muutes Java teenuse mõju ulatuses nähtavaks isegi siis, kui selle kood ei sisalda otsest veeruviidet.
Mõjuanalüüsi funktsioon rakendab seda keeltevahelist sõltuvusgraafikut , et vastata igale skeemimuudatusele eelnevale konkreetsele küsimusele: arvestades seda kavandatavat muudatust, loetlege kõik mõjutatud komponendid igas keeles ja igas kihis. Vastus on struktureeritud, loetletud loend, mis on otse seotud ülaltoodud mõjuaruande malliga. See ei ole hinnang ega arendaja parim mälestus sellest, mida muudatus võib mõjutada, vaid struktuuriline tuletis tegelikust koodist.
Ettevõtte otsinguvõimalus muudab sõltuvuste inventuuri päringuid teostatavaks kogu muudatuste haldamise elutsükli vältel: leia sekunditega iga programm, mis viitab kindlale veerule COBOLi, Java, Pythoni ja SQL-i kaudu samaaegselt miljonite koodiridade ulatuses.
Meeskondadele, kes haldavad skeemimuudatusi keskkondades, mis ulatuvad pärand moderniseerimine Programmide puhul, kus andmebaasi võidakse jagada moderniseeritava COBOL-i suurarvutirakenduse ja seda asendavate moodsate Java-teenuste vahel, ei ole keelteülene mõjuanalüüs valikuline. Moderniseerimisele ülemineku ajal on nii pärand- kui ka moodne kiht samaaegselt tootmises. Java-teenuse seisukohast ohutu skeemimuudatus võib olla tundmatu COBOL-programmidele, mis sellega koos töötavad. SMART TS XL näeb selle piiri mõlemat poolt korraga.
Skeemimuudatused ei riku rakendusi. Analüüsimata skeemimuudatused küll.
Selle juhendi alguses mainitud juurutamise tõrge, Java-teenuse katki jätnud veeru ümbernimetamine, COBOL-paketttöö ja kolm tundi pärast avaldamist tekkinud aruandlustorustik – nende migreerimisskriptiga polnud midagi valesti. Skript käivitati õigesti. Veerg nimetati ümber täpselt ettenähtud viisil. Ebaõnnestus aga analüüs, mis oleks pidanud sellele eelnema: kõigi algsele veerunimele viitavate rakenduste loetlemine, igaühe värskendamise kontrollimine ja juurutamisjärjestuse andmebaasi ja iga tarbija vahelise järjepidevuse valideerimine.
Skeemi mõjuanalüüs ei ole bürokraatlik kontrollpunkt. See on töö, mis muudab riskantse juurutuse ohutuks, teisendades muudatuse tundmatu ulatuse loetletuks ja kontrollitavaks loendiks kõigest, mida see mõjutab. Migratsiooniskript võtab minuti. Mõjuanalüüs võtab nii kaua aega kui vaja. Tootmisintsident, mida see ära hoiab, võtab päevi.
