Динамична структура на базата данни

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

С тази идея се сблъсках за пръв път докато разглеждах списъка с одобрените от катедра ИТК на УНСС теми за дипломни работи на специалност Бизнес информатика, випуск 2008. Точната формулировка беше „Проектиране и изграждане на програмен интерфейс за поддръжка на динамична структура на бази данни” и привлече интереса ми, защото, както разбрах от пояснението, включваше програмиране, бази данни и нещо, за което знаех твърде малко.

За два месеца събрах не многото материали свързани с динамичната структура, проучих ги и в този пост ви предлагам отговорите на три от важните въпроси свързани с нея:

  • Какви проблеми решава тази концепция?
  • Как го прави?
  • Каква е схемата й?

Проблемите

Динамичната структура решава три фундаментални проблема свързани с разработването на информационни системи:

  • Неопределеността и ограничеността на експертното знание – това означава, че често софтуерните инженери работят с недостатъчна, относителна и неструктурирана информация за предметната област на системата, която създават.
  • Промяната на гледните точки – тук има два под проблема: първият е, че различните хора има различни виждания по един и същи въпрос, а вторият е, че на всеки човек си мени мнението.
  • Сходството на елементи на различни системи – или казано по друг начин, писането на преизползваем код по ред причини не винаги е възможно. Разбира се, това би могло да се разгледа и като следствие от горните два проблема, но според мен има и самостоятелно проявление.

Освен това, тя заобикаля недостатъци на Релационния модел като:

  • В релационната база данни може да се описва състоянието на същностите и взаимодействията между тях, но не може да се описва поведението им.
  • Информационната система трябва да се променя с всяка промяна в структурата на базата данни.
  • Бързодействието и обема на данните са обратно пропорционални.

Метадизайн

В Релационния модел таблиците са описани така, че еднакво добре да гарантират референциална цялост чрез външните си ключове, уникалност чрез първичните си ключове, коректен резултат от запитвания към тях и т.н., без да се интересуват от конкретния проблем, който е описан в тях.

Динамичната структура е резултат от прилагането на същия подход при описанието на данните. Чрез него, при проектирането, обектите и техните описания се абстрахират  както от самата структура, така и от приложението, което ще се изгради в последствие. При него базата данни се превръща в единна структура за съхранение на мета данни за реалните обекти и конкретни техни проявления.

От тази гледна точка и с цел разграничаване на описанието на обектите от идентификацията им при метадизайнът са необходими и достатъчни следните таблици и връзки:

  • Таблица Тип  – тази таблица съдържа номенклатурата на различните бизнес обекти (видове същности), които се регистрират в базата данни. Тя е разширяема и необходима, за да се осигури различаемост на обектите и типа на описанието им. Характерното за тази таблица е, че за да не се позволява въвеждането на две същности с еднакви имена е създаден допълнителен индекс по колоната TypeName.
  • Таблица Същност – в тази таблица се съдържа номенклатурата на всички регистрирани в базата данни бизнес обекти. Тя е произволно разширяема и не съдържа конкретно описание на обекта. Иначе казано, тя представлява описание на това от кой тип същност е всеки един конкретен бизнес обект.
  • Таблица Характеристики– тук се съдържа номенклатурата на необходимите атрибути на всички бизнес обекти, които са интересни за приложението. Благодарение на това описанието на бизнес обектите, тази номенклатура също е произволно разширяема. За да се гарантира качеството и правилната интерпретация на данните всеки атрибут (наречен характеристика) се описва по отношение на:
    • Неговата задължителност (Mandatory);
    • Неговата повторяемост в рамките на едно и също описание на един и същ обект (Reoccurrence);
    • Връзката с му с други обекти (т.е. Описанието на връзките между обектите в посоката от 1 към Много т.е. Връзката дете-родител) (Relationship);
    • Начинът на въвеждане на датата, ако ще се съхранява история – от потребителя или служебно (dateenter);
    • Тип на стойността, с която се конкретизира в описанието (valuetype);
    • Допълнителни ограничения върху стойността (Checks);
  • Таблица Шаблони  – за да се осигури адекватен набор от атрибути, а не изобщо описание, което позволява да се гарантиран и възможност за специфична интерпретация на едноименни атрибути, е мета модела се подържа и шаблон за всеки тип бизнес обект – конкретен набор от атрибути за конкретен тип. Тези шаблони са разширяеми както в рамките на отделен  тип, така и с нови типове обекти.
  • Таблица Описание – чрез тази структура в мета модела, се осигурява съхранението на конкретните данни за всеки обект. Съдържанието на тази структура се контролира от „описанието” на атрибутите в него.

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

  • Връзката на таблиците Тип и Същностсе осъществява чрез колоната TypeID. Нейните характеристики са:
    • Вид – едно-към-много (от Тип към Същност);
    • Ограничение при триене – редовете от Тип не могат да бъдат изтрити, ако стойностите на първичните им ключове участват в редове от Същност.
    • Ограничение при промяна – стойностите на първичните ключове на редовете от Тип не могат да бъдат променяни, ако участват в редове от Същност.
    • Тъй като попълването на полето typeid в Същност е задължително, а то се явява и външен ключ за тази таблица, то стойността, която ще бъде записана там трябва вече да съществува в Тип.
  • Връзката на таблиците Тип и Характеристикисе осъществява чрез колоната typeid. Нейните характеристики са:
    • Вид – много-към-много (от Тип към Характеристики) – всеки тип същност може да има повече от една характеристика, както и всяка характеристика може да е част от описанието на повече от един тип.
    • Таблица посредник – Шаблони.
    • Ограничение при триене – редовете на Тип и Характеристики не могат да бъдат изтрити, ако стойностите на първичните им ключове участват в редове от Шаблони.
    • Ограничение при промяна – стойностите на първичните ключове на редовете и от Тип и от Характеристики не могат да бъдат променяни, ако участват в редове на Шаблони.
    • Самото естество на връзката задължава стойностите, с които се попълва таблицата Шаблони да фигурират предварително в таблиците Тип и Характеристики.
  • Връзката на таблиците Същност и Описаниесе осъществява чрез колоната entityid. Нейните характеристики са:
    • Вид – едно-към-много (от Същност към Описание).
    • Ограничение при триене – редовете от Същност не могат да бъдат изтрити, ако стойностите на първичните им ключове участват в редове от Описание.
    • Ограничение при промяна – стойностите на първичните ключове на редовете от Същност не могат да бъдат променяни, ако участват в редове от Описание.
    • Тъй като попълването на полето entityid в Описание е задължително (като част от първичния ключ на таблицата), то стойността, която ще бъде записана там трябва вече да съществува в Същност.
  • Връзката на таблиците Характеристики и Описаниесе осъществява чрез колоната propertyid. Нейните характеристики са:
    • Вид – едно-към-много (от Характеристики към Описание).
    • Ограничение при триене – редовете от Характеристики не могат да бъдат изтрити, ако стойностите на първичните им ключове участват в редове от Описание.
    • Ограничение при промяна – стойностите на първичните ключове на редовете от Характеристики не могат да бъдат променяни, ако участват в редове от Описание.
    • Тъй като попълването на полето propertyid в Описание е задължително (като част от първичния ключ на таблицата), то стойността, която ще бъде записана там трябва вече да съществува в Същност.

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

Прилагането на мета-дизайна при проектирането на база данни може да се извърши изцяло или да се приложат само отделни негови идеи, като се комбинира с традиционния стил на проектиране.

Схемата

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

Advertisements

Вашият коментар

Попълнете полетата по-долу или кликнете върху икона, за да влезете:

WordPress.com лого

You are commenting using your WordPress.com account. Log Out /  Промяна )

Google+ photo

You are commenting using your Google+ account. Log Out /  Промяна )

Twitter picture

You are commenting using your Twitter account. Log Out /  Промяна )

Facebook photo

You are commenting using your Facebook account. Log Out /  Промяна )

Connecting to %s

%d bloggers like this: