C, PHP, VB, .NET

Модерните програми и най-вече интернет приложения са наложили тенденцията за изолиране на информацията от програмния код, а базите данни и по-конкретно релационните бази от данни с език SQL са се наложили като най-интуитивно и най-подходящо за момента решение за учебна среда. Затова курсът по "бази от данни" е основен за всички компютърни специалности в университетите и обикновено се фокусира именно в релационните бази от данни. Обикновено, и с основание, той се изучава във втори или трети курс от образователно-квалификационна степен "бакалавър". Логиката на стъпаловидно надграждане на знанията [1] подсказва, че е нужно първо да научим студентите как да създават програми (изучавайки предмети по основи на програмирането, обектно-ориентирано програмиране и структури от данни) и чак след като са усвоили тези знания да ги научим по какъв начин е удачно да се складира информацията, която те са обработвали с тези програми.

В настоящата статия ще предложа един подход за структуриране и преподаване на встъпителен едносеместриален курс по бази от данни с хорариум от 2 часа седмично лекции и 2 часа седмично упражнения. От самото начало искам да отбележа, че обикновено този хорариум се оказва недостатъчен за достатъчна практическа подготовка на студентите, затова в програмата трябва да се предвиди и самостоятелна работа по курсови задачи. Ще следвам традицията на учебните програми в българските, а и в почти всички международни университети и затова ще считам, че студентите вече са минали курсове по процедурно програмиране и обектно-ориентирано програмиране. Целта е да се направи един дидактичен подход към плавен преход между учебните предмети в програмата, както и да се направи стъпаловидно надграждаща се структура на знанията вътре в предмета бази от данни. Основните знания и умения, които трябва да се усвоят чрез такъв курс са проектиране на бази от данни с малък обем информация и въведение в боравенето с езика SQL.

1. Въведение

Както във всяка методика на обучение и в преподаването на бази от данни учениците (в случая студенти) трябва да получат отговори на фундаменталните въпроси "защо", "какво" и "как" [2]. За конкретния учебен предмет можем да ги формулираме като "защо да складираме информация в бази от данни", "какви бази от данни да използваме" и "как да складираме и използваме въпросната информация в тях". В курсът по бази от данни лесно се отговаря на първият въпрос, а на другите два е нужно целенасочено излагане на теория и практически упражнения.

2. Защо да складираме информация в бази от данни

Още от курсовете по процедурно и още по-силно застъпено в курсовете по обектно-ориентирано програмиране студентите достигат до нуждата от това програмите да записват изчисленията, които са направили така, че да могат да бъдат използвани и в бъдеще. В тези курсове обикновено данните се записват в текстов или бинарен файл, но естествено като спазват изключително стриктна структура. Тривиалният пример е със "списък от студенти", където на всеки ред се пази първото, фамилното име и факултетния номер на даден студент, като посочените полета са разделени чрез специален разделител (интервал, табулация или друг "специален" за програмата символ). Всъщност именно тези примери са една целенасочена пропедевтика към табличното представяне на информацията в релационните бази от данни.

Именно в уводната лекция по бази от данни е удачно да се направи препратка към примерите преподавани по курсовете по програмиране, като се постави следната задача от "зоната на близкото развитие" [2] на студентите: как различни програми, писани от различни програмисти да достъпват едни и същи данни по унифициран начин. Естествените проблеми, които могат да се засегнат на първо място са разделителите на информацията и нейната подредба - различните програми трябва да се "наговорят" за единен стандарт. На второ място идва проблемът с излишеството на информация - различните програми могат да боравят с различно количество информация. Не на последно място стоят проблемите по многопотребителски достъп и сигурност - как програмите да се синхронизират така, че да могат да работят едновременно с едни и същи данни без да навреждат една на друга. Начинаещи програмисти веднага ще осъзнаят множеството проблеми, които изграждането на една такава система поставя. Така по съвсем естествен път ще се достигне и до идеята за създаване на "интерфейс" за достъп до данните, чрез който програмите да достъпват информацията. Виждате, че както споменах по-горе - отговорът на въпроса "защо да складираме информация в бази от данни" идва съвсем интуитивно за студентите и не изисква време и специализирана методика.

3. Какви бази от данни да използваме

След като студентите са подготвени за използването на споменатия "интерфейс" за достъп до информацията, то предварително трябва да им поставим въпроса "а по какъв начин все пак се складира тази информация зад този интерфейс". Това както се досещате е фундаментален въпрос и в зависимост от специалността на студентите може да се стигне до различни нива на задълбочаване. Като основен проблем пред студентите на първо място трябва да поставим проблема за "излишество на информацията".

Тъй като още от училищните им години те би трябвало да бъдат запознати с табличното форматиранe на данни с електронни таблици, то е много подходящо да им бъде даден пример с таблица, в която има именно проблем с голямо излишество на данни. Такъв пример с електронна таблица би бил изключително подходящ и като пропедевтика за по-нататъшното таблично представяне на данните извлечени от релационна база от данни. Обикновено студентите сами успяват да се досетят, че за да се справим с този проблем е удачно да разделим информацията в две или повече таблици. Рядко обаче успяват да измислят теоретичен модел на това как тези таблици биха могли да бъдат свързани логически помежду си. Затова преподавателите могат да използват аналогия с вече изучените указатели от курсовете по програмиране - можем спокойно да им кажем, че ние ще правим подобни "препратки" (връзки) от едната таблица към другата като за всеки запис в едната ще пазим нещо подобно на указател "сочещ" към другата. Естествено аналогията с указател не е напълно точна - затова е коректно да поясним впоследствие с изчерпателни примери за различните видове връзки. Все пак използването на подобна междупредметна връзка е подходяща за по-лесното навлизане в материала.

След като бъде изяснена нуждата от разделение на информацията, то самите студенти ще повдигнат логичен въпрос - какви са критериите, по които разделяме информацията? Най-удачно, а и широка практика е да се започне с взаимовръзки между обекти с йерархична зависимост. Тъй като примерите на изградена йерархия на обектите от реалният живот са изключително много, то и подобни примери се измислят и реализират изключително лесно. Класическите примери за йерархия във фирма, университет, държавна администрация и т.н. могат да бъдат представени последователно, като това съответно убеди студентите, че критерият за разделяне на информацията може да копира директно йерархичното разделение на обектите от реалния свят.

След като този тип по-интуитивни бази от данни са усвоени, е време за даването на примери с модели, в които няма ясно изявена йерархия на обектите. Така зоната на близкото развитие на студентите се насочва към измисляне на по-сложни взаимовръзки. Отново е добре да показваме примери, в които модела на базите данни описва еднозначно реалните обекти - да няма нужда от интерпретация и да има възможно най-малко нужда от тълкуване на условията на задачите. Именно тук - при появата на по-сложни взаимовръзки - става удачно да се започне с т.нар. "ER диаграми". Отново е добре да се направи аналогия с "блок-схемите" от програмирането, с които студентите са правили модели на алгоритми. Добре е знанията да не бъдат въвеждани като нещо фундаментално ново - така ще бъдат запаметени много по-лесно.

След преминаване през по-лесните примери вече може да се премине към моделиране на значително по-сложни условия на задачите, в които целенасочено е пропусната малка, но ключова информация. По този начин студентите ще бъдат провокирани да разсъждават творчески - ще намират различни решения на една и съща задача в замисимост от интерпретацията на условието.

След като студентите натрупат достатъчно практически опит, може да се пристъпи и към по-теоретичната част от учебния материал. Бих препоръчал да се обърне сериозно внимание на релационната алгебра. Тази тактика "практиката да предхожда теорията" е значително по-ефективна от дедуктивното изложение на материала, защото провокира значително повече интереса на студентите.

След като споменатите модели бъдат усвоени, можем спокойно да преминем и към формалното дефиниране на понятието "релационна база данни", и да направим "изображение" на ER диаграмите в таблици (за която по-рано направихме целенасочена пропедевтика). Този преход е сравнително лесено усвоим от студентите, защото следва строги и ясни правила:

- Имената на класовете обекти се изобразяват в имена на таблици;
- Имената на характеристични обекти се изобразяват в имена на таблици;
- Имената на атрибути на класове обекти и характеристични обекти се изобразяват в имена на колони от въпросните таблици;
- Връзките 1:M се изобразяват в допълнителна колона към една от таблиците (тази, която стои от страната на "M" на диаграмата);
- Връзките 1:1 се изобразяват като допълнителна колона към една от таблиците (стандартно видовата когато имаме йерархия), като за разлика от връзките 1:M, се поставя допълнителен атрибут unique (забраняващ повторенията);
- Връзките M:M се изобразяват като допълнителна "помощна" таблица с две колони, всяка от която е външен ключ към съответната свързвана таблица, а двете взети заедно са първичен ключ;
- Уникалните характеристики на обектите се обозначават с Primary Key, а връзките между различните таблици се обозначават с Foreign Key.

Наистина догматично, но все пак по показания начин ние отговаряме конкретно на въпроса "какви бази от данни да използваме". Отговорът идва от практиката, където най-широко са се наложили именно релационните бази от данни. Модерните алтернативи, като например бази от данни от тип NoSQL би следвало да се изучават в по-късен етап на обучението, препоръчително в специализиран курс.

4. Как да складираме и използваме информация от бази от данни

Рядко в учебниците се дава смесено теорията за проектирането на бази от данни с тяхното практическо изпълнение. Обикновено за практически цели има отделни учебници и книги, най-често свързани с езика SQL. Рядко в учебници като [3] се дава достатъчно последователна информация едновременно за проектирането на бази от данни и практически примери с езика SQL. В един обучителен курс е важно да се направи тази връзка между проектиране и конкретна разработка. В противен случай в студентите ще останат знания, които на този етап не са приложими и по тази причина не докрай осмислени. Такива знания с времето избледнеяват и се губят. Естествено, може курсът "бази от данни" да бъде разделен формално на две части - проектиране на бази от данни и използване на бази от данни чрез език SQL, но те трябва задължително да са последователни и без голяма времева "дупка" помежду си. Езикът SQL ни дава средство за практическото приложение на теорията, която обикновено се разглежда в курса по "бази от данни" по време на лекции - затова би следвало да се изучава предимно в семинарни и практически упражнения.

Именно изучаването на езика SQL би отговорило по един начин на въпроса "как да складираме и използваме информация от бази от данни". По тази тема има много учебници и книги, но по мое лично виждане, смея да твърдя, че в повечето от тях има сериозни недостатъци от методическа гледна точка. Най-вече това се вижда в "стандартната структура", които почти всички (а може би дори всички) учебници използват като последователност за надграждане на знанията на учащите. В учебниците със смесено съдържание от теория на бази от данни и езика SQL като [3] пък често се забелязва изискване за прекалено високо ниво на предварителна подготовка най-вече за основните знания за езика SQL - нещо, което всъщност се предполага, че трябва да бъде изучено в курса на обучение. За да покажем това, нека разгледаме най-често срещаната последователност на главите в учебници по SQL:

- Обучението по SQL започва с прости оператори SELECT за извличане на данни от базата данни;
- Надграждане на операторите SELECT чрез извличане на информация от множество таблици (JOIN);
- Вложен SELECT и "прескачане" между таблици;
- Агрегатни функции, групиране и сортиране;
- Оператори INSERT за вмъкване на данни;
- Оператори UPDATE за обновяване на данни;
- Оператори DELETE за изтриване на данни;
- Оператори CREATE, DROP и ALTER за създаване на таблици;
- ... и т.н. следват по-специфични за конструкции като трансакции, VIEW, INDEX, тригери и др.

От тази последователност се вижда, че студентите на най-първо се научават да четат информация от бази от данни (оператор SELECT). Това едва ли следва пътя на практическата логика, защото ето как изглежда проектирането на една база данни в реални условия:

- Проектиране на системата (ER диаграми и т.н.);
- Създаване на базата данни (заявки CREATE);
- Попълване на информация в базата данни (заявки INSERT);
- Боравене с тази информация чрез SELECT, UPDATE, DELETE и т.н.

Наистина невъзможно е ние да четем информация от таблица, която все още не съществува. Затова в упражненията, които се провеждат, се дават готови бази от данни, върху които се изпълняват заявки. Моята лична практика показва, че този подход води до "накъсване на знанията" при повечето студенти. Още в началото те изпитват затруднения с това да разберат какви са типовете данни (и защо са такива), как са създадени тези таблици и защо са свързани точно по този начин, откъде идва (как точно е складирана физически) тази информация и др. Много по-лесно би било за студентите да разберат връзките между няколко таблици, ако самите те са ги направили, а не ако им се дават наготово. Затова SELECT оператора като, че ли "се е показал" прекалено рано в учебния план, и от там това води до съпътстващи проблеми в усвояването му. Затова бих препоръчал обучението да започне първо със заявки CREATE, последвани от INSERT, и чак тогава SELECT.

Като контрапункт на това предложение обаче колегите преподаватели изтъкват нещо, което до известна степен е вярно - за студентите заявките CREATE са сравнително трудни. Наличието на прекалено много CONSTRAINTS и съпътстващи ги чисто теоретични проблеми от проектирането на базата данни са прекалено сложна сложна материя, а в същия момент много трудна за осъзнаване без достатъчно практически упражнения с другите оператори (SELECT, INSERT, UPDATE, DELETE) - човек трябва да се сблъска с проблемите преди да започне да ги разрешава. Именно поради тази причина при въведението в езика SQL се е наложила тенденцията да се започне с най-лесното (прост оператор SELECT), което при това дава практически резултат (на екрана излизат резултатни таблици). Последното естествено е предимство, който не може да бъде подценявано.

Така по естествен път достигаме до моето предложение за "компромисен вариант". Предлагам първоначално да се започне с оператор CREATE, но в свой силно опростен вариант - без да се изучава всичко в детайли. Неговите специфики да бъдат изяснявани впоследствие, като студентите се връщат назад и допълват знанията си за него. Така усвояването на оператора няма да бъде тежко за студентите от самото начало, а в същия момент знанията ще се попълват последователно. Така определено ще се избавим от традиционния масов проблем на студенти, които могат да употребяват само оператор SELECT, а останалите са пропуснати поради натрупани пропуски и трудности в правенето на адекватна връзка между различните знания. Поради тази причина аз предлагам следната последователност за въвеждане на знания по езика SQL:

- Изброяване на основните типове данни в SQL: INT, FLOAT, CHAR, VARCHAR и т.н. и показването на тяхната аналогия в програмирането;
- Алгоритмично въвеждане на възможно най-опростени заявки CREATE: представяне на прост метод, който да може да трансформира ER диаграма в релационна база данни, като НЕ се обръща внимание на иначе важни свойства като наличието или не на стойности NULL, DEFAULT стойности, CHECK правила, каскадно изтриване, както и други по-специфични CONSTRAINTS;
- Във вече създадена от студентите база данни се тренират заявки INSERT от най-прост вид и отново алгоритмично, без да се демонстрират проблеми като например интегритет на данните;
- Въвеждане на прост оператор SELECT, с който се четат въведените от студентите данни;
- Надграждане на операторите SELECT чрез извличане на информация от множество таблици (JOIN);
- Въвеждане на вложен SELECT;
- Разглеждане на агрегатни функции, групиране и сортиране;
- Надграждане на знанията за операторите INSERT чрез допълнителни знания, които са придобити чрез операторите SELECT;
- Изучаване на оператори UPDATE;
- Изучаване на оператори DELETE, като тук се поставя специално внимание на проблеми, които са се появили впоследствие на неизползването например на каскадно изтриване в началото. Непосредствено "връщане" към оператор UPDATE, където се отбелязва, че съществуват сходни проблеми, които са още по-трудно забележими от разработчика;
- Припомняне на знанията за оператор CREATE, разглеждане на допълнителни проблеми поради липса на знания за функционалност и съответното въвеждане на допълнителните пропуснати знания за различни CONSTRAINTS;
- Въвеждане на командите ALTER, чрез които студентите "поправят" недостатъците на създадените от тях бази от данни и отново тренират функционалностите, които са изучени преди това;
- Разглеждане на командите DROP;
- Следва обща, но не задълбочена информация за по-специфични за функционалности като VIEW, INDEX, трансакции, съхранени процедури, тригери и др. - дава се обща представа на студентите за тях само ако има останало свободно време. Тези знания следва да се разгледат подробно в по-задълбочен курс по SQL и бази от данни.

Смятам, че така представената методика ще доведе до много по-плавно и по-ясно усвояване на нужните знания, без да се получава накъсване на знанията. Това, че в началото студентите не получават изчерпателна информация за някои от операторите, не означава, че те няма да бъдат ефективно усвоени по-късно по време на курса. Неразбирането на това може би води и до текущата практика на преподаване по бази от данни - може би университетските преподаватели се страхуват да "свалят нивото" и да преподават част от материала прекалено опростено за известен период от време. За мен е по-важно хората да разберат материала та макар и в опростен вид, отколкото да го зазубрят изчерпателно.

Тук е мястото да отбележа специално учебника [4], който е изключително добре структуриран за едно целенасочено практическо обучение за системата MySQL. Именно подобен стил на изложение е изключително подходящ за практическо ръководство, но естествено свързан и с добре утвърдена теоретична основа.

5. Продължение на обучението по бази от данни

Както споменах, тази методика предполага курсът по бази от данни да е встъпителен, но в никакъв случай не изчерпателен. Чрез него студентите биха добили едни основни практически умения за работа с бази от данни, но не бихме казали, че ще бъдат изградени специалисти. Поради тази причина курсът трябва по възможност бързо да бъде последван от втори, по-специализиран курс по бази от данни, в който да се дадат формално пълните възможности на всички разгледани във встъпителния курс оператори (припомняне и обобщение на знанията от езика SQL), припомняне и обобщение на знанията от проектиране на бази от данни и да последва задълбочено теоретично и практическо разглеждане на физическото представяне на данните, оптимизация, теория за индексите и търсенето на информация, теория на трансакциите, съхранени процедури и тригери, сигурност при базите данни, разпределени бази от данни, обектни бази от данни, data mining и др. В зависимост от специалността на студентите, тези знания могат да бъдат разделени и в повече от един учебен предмет. Както споменах в началото един такъв предмет непременно би трябвало да бъде практически насочен курс по NoSQL, тъй като тази технология добива все по-широка популярност.

6. Заключение

Смятам, че изложената методика за обучение по встъпителен курс по бази от данни ще даде едновременно последователно надграждащи се знания и една добра основа за лесното им интегриране в учебната програма за следващи учебни предмети. Впрочем тази методика съответства добре на повечето съществуващи учебни програми. Един такъв курс би бил добър както за начален курс по бази от данни за информатици, който ще бъде продължен с други по-задълбочени, така и за самостоятелен курс за основи на базите данни за други специалности, за които се очаква усвояването на базови познания, но не и задълбочаване в материала.

[1] Ганчев И, Грозев С - "За два фундаментални подхода към развитието на научно познание и тяхната употреба в дидактиката по математика"; 6-та средиземноморска конференция за обучение по математика 2009

[2] Методика на обучението по математика (обща част), Благоевград 2002

[3] Ramakrishnan R., Gehrke J - "Database management systems (second edition)", 2002

[4] DuBois P. - "MySQL Cookbook", O'Reilly, October 2002.