Данните обикновено се свързват с програмирането и в съвременния информационен свят се представят в три логически еквивалентни версии: данни, описани и използвани в програма на език за програмиране; данни в системи за бази данни; данни в разпределени информационни системи. Съвременното програмиране даде относителна свобода само на първия вариант на формализиране на информацията. Вторите две опции са повече или по-малко надеждни форми за предоставяне на информация и връзки между нейните компоненти.
Минали и настоящи данни
Основната позиция на езиците за програмиране е точното описание на данните и алгоритмите. Компютрите не "представят" никакъв шанс за несигурност: има нещо, върху което трябва да се действа и има команда, която изпълнява това действие.
Съвременната концепция се основава на много по-висока основа: има даденост и каква точно ще бъде тя се определя от мястото на нейното използване. Във всеки случай, по време на употреба, данните се проверяват автоматично и се преобразуват в правилния тип. Съвременният програмист не е длъжен да се грижи за тяхното предварително описание и спазване на съвместимостта на типове в алгоритъма.
Процес на преход:
- от въведени данни и тяхното задължително описание преди употреба;
- към невписани данни и свобода от каквото и да е задължение за описването и използването им.
Всъщност можем да разпознаем относителното облекчаване на изискванията за формализиране - то е достъпно само в средата на съвременните инструменти за програмиране. По време на изпълнение типът на всяка дата е фиксиран и последователността на командите е добре дефинирана.
Видове и моделиране
Математиката и физиката, търговията и производството, икономиката и други области, където се използват числа, винаги са оперирали с данни и не са придавали никакво значение на концепцията за тип. Фактът, че числата могат да бъдат цели или дробни, всъщност няма значение.
Всяка конкретна формула или конкретно действие може да даде цяло число, безкрайна дроб, реално или комплексно число. Досега има такива чудеса на ума като безкрайно малки и безкрайно големи. Освен това тези чудеса дори имат свойства.
В програмирането все още няма свобода. Всичко трябва да бъде строго формализирано. Концепцията за данни е преди всичко тип:
- цяло число;
- boolean;
- char;
- низ и така нататък.
Имената на типовете може да се различават в различните езици за програмиране, но винаги има цяло число или реално число, булева стойност, символ,линия. Все още има останки и конкретни идеи: цяло число без знак, код, байт, дума, двойна дума, низ с фиксирана дължина.
Концепцията за данни в система от данни няма свобода. Езикът SQL - "международен" (има диалект за всяка съвременна база данни) - не толерира никакви неточности не само в данните, но и в sql заявките. Грешка в заявката е гаранция за липсата на резултат. Изобщо няма нужда да говорим за нарушения на описанията.
Моделирането на информационни процеси и представяне на данни е единственият сигурен начин за изграждане на структура, която може да се развива и адаптира към променящите се условия.
Динамика на оригинала
Естествената информация е непрекъсната промяна. Да се даде формално описание и концепция на модел на данни в конкретна предметна област означава да се решат три проблема:
- определете какви данни има тук;
- формализирайте връзката между тях;
- опишете процеси за промяна на данни и връзки.
Пример за набор от данни на прост алгоритъм в JavaScript - намалено копие на модела дори на най-солидна система за управление на база данни.
Просто във втория случай експертите и специалистите, когато проектират структури от данни, таблици и връзки, обикновено не виждат (наистина е трудно да се обхване голямо количество естествена информация) същността на нещата и Получава се тромав, неразработен набор от купища данни, докато в предметната област информацията за източник циркулира свободно и лесно.
Статичновъзможно
Честа практика на JavaScript е да се включва код, прикачен към страница, и функции, присвоени на събития в етикетите на страницата. Така или иначе маркерите на страницата дефинират данните, които даден уеб ресурс приема, променя или създава.
Ако концентрирате кода на манипулатора много внимателно върху събитията на елемента, а не върху кода на страницата като цяло, това е най-добрият изход. В идеалния случай, когато кодът не въвежда нови данни или не коригира наличните данни, а се фокусира върху това какво точно има в определен момент от време.
Всъщност, ако дефинирате понятието "данни" като минимално статично описание на изходната информация и го следвате, тогава това означава, че имате шанс за успех.
По отношение на базите данни нещата са много по-сложни. Всеки JavaScript код "осигурява" функционалност на страницата. Всяка база данни е колекция от таблици, връзки между тях, съхранени процедури, заявки и функционалност, достъпна отвън.
Статичността е проблемът на всеки алгоритъм. Съвременната концепция за данни е статична: число, низ, знак и т.н. При обработка или при запис в таблица на база данни всичко се оказва гладко. Но кога оригиналът придобива различно измерение или значение? Вариант първи: променете знака, но връзките и заявките могат незабавно да попаднат.
Статика и обекти
Определянето на понятието "данни" като обект променя драматично ситуацията. Обектът има своя собствена структура. Тук можете да използвате всяко описание на всякакви променливи. Ролята няма да играе. Обектът има методи, чрез които данните са достъпни. Тъй като всичкоизползвани в областта на програмирането, тоест три основни метода: четене, писане, промяна. Можете да добавите още за сравнение, търсене, клониране и т.н.
Тематичната област налага набор от свойства върху всяка информация. Така се оказва, че понятието данни се трансформира в един вид описание, което може да се променя динамично. Статичността вътре в обект дава динамика извън него.
Променяйки комбинацията от статични дескриптори вътре в обект, не е нужно да се притеснявате за динамиката на неговите отношения с други обекти.
Програмиране и представяне на данни
Какво са данни? Общественото съзнание вече е свикнало с информационните технологии, работи в облаците и разполага с контейнери във виртуални пространства. Сега не само професионални програмисти и потребители, но и обикновени хора са компетентни по въпросите на информацията и нейното използване.
Но какво е програмиране? И до днес общественото мнение дава следната дефиниция на това понятие и неговите понятия:
- Информацията и данните са основните понятия, използвани в компютърните науки.
- Данните са по определен начин получени и записани наблюдения спрямо заобикалящата реалност.
- Те са прости и сложни (структури), първични и вторични.
- База данни е колекция от независими материали, представени по систематичен начин, така че да могат да бъдат намерени, модифицирани и използвани.
Колко обективно е това? Авторитетни авторимисля така. Реалната практика има тенденция да гарантира, че всяка предметна област определя своята правилна система от данни и дава всяка възможност за изграждане на добър динамичен модел.
Не е необичайно клиент (потребител) да налага собственото си мнение на програмист (дизайнер на база данни) за това как и какво да прави. От гледна точка на програмирането, всяко желание на клиента може да бъде изпълнено с най-голяма прецизност.
Имам нужда от Oracle за решаване на проблема с бюджетирането за поддръжка на селското водоснабдяване (сграда 21 в селото) - добре. MySQL е необходим за организиране на система за проследяване на пощенски пратки за всички пощенски станции в Русия - всичко също ще работи.
Винаги можете да съставите всеки алгоритъм и да осигурите достъп до всяко представяне на информация в рамките на дефиницията на концепцията за данни, която е установена от разработчика на системата за управление на базата данни или езика за програмиране. Въпросът е различен: как да го направя с минимални разходи в максимална динамика?
Бази данни, примери
Проста основа се създава без модел. Основните понятия за данни и комуникация са малки, функционалността е много проста. Например, за висше учебно заведение се нуждаете от:
- маса на учителите;
- групова таблица (номер на ключ и група);
- обща таблица на учениците (използват се групови ключове).
Деканът иска да знае напредъка на учителите. Таблицата с учители има полета:
- фамилно име;
- име;
- патроним;
- номер на контролирана група.
Ученическата таблица има полета:
- фамилно име;
- име;
- патроним;
- дата на раждане;
- GPA (за всички предмети);
- групов номер.
Може да има поне две опции за вземане на проби: като използвате името на учителя, можете да отидете до номера на групата и да видите всички ученици и техните средни резултати, или по фамилното име на учителя и последния името на ученика, можете да видите средния резултат от последния.
Дори в толкова проста версия проблемите са гарантирани и нещо ще трябва да се промени. Ситуация: учителят се разболя, друг месец го замества, което означава, че ръководи две групи. Има само едно поле под един номер на група в таблицата на учителите.
За да разрешите проблема, трябва да добавите дублирано поле. И ако двама се разболеят, тогава добавете три полета. Така че масата на учителите започва да расте от нулата.
Има и друга опция: заменете цифровото поле на груповия ключ със символично. След това, всеки път, когато изберете, ще трябва да конвертирате низа в поредица от ключове и една sql заявка ще се превърне в няколко.
По-обещаващ пример е не да се правят таблици, а да се правят обекти. Тогава учителят е обект и може да има няколко контролирани групи. Но винаги е един обект. Обектът учител има уникален ключ, но може да има множество контролирани групи. Групата има и уникален ключ. Студент също.
И трите позиции не само са налични в рамките на задачата, но могат да бъдат доразвити.
Обектно-ориентирани бази
Лидери в информационната индустрияпредлагат класически релационни бази данни. Те са тествани от живота, работят, безопасни са, надеждни и в случай на проблеми ви позволяват да възстановите информацията.
Обектно-ориентирани бази данни (OODB) започват да се разработват в средата на 80-те години и според авторитетни автори са обещаващи и до днес. Но досега, с изключение на фундаменталните теории и концептуалните положения, няма OODB, който да е постигнал същия рейтинг и разпространение като MySQL, MS SQL Server или Oracle във всичките му разнообразни въплъщения.
Но какво ще стане, ако дефиницията, концепцията за данни, типове, атрибути, класове, йерархии е предложена от разработчик, чийто рейтинг е недостатъчен, за да създаде общност от програмисти, които изповядват манталитета на този OODB? Ще трябва да разчитаме на собствените си сили.
Повече от тридесет варианта на OODB са създадени в средата на Linux. Но къде е гаранцията, че създадената база данни няма да изисква повече функционалност? Средата на Windows не предлага много гаранции в тази област.
Обектно-ориентирано решение
Въпреки това, има решение. Използвайки MySQL като пример, можете да покажете как стандартните релационни таблици се превръщат в обектно-ориентиран модел на решавания проблем.
Тук няма база данни, но има среда за формиране на собствена система от обекти. Силата на MySQL се използва само като релационна памет за таблици от информационни редове. Логиката на използване се определя от самия разработчик. По-специално, има таблица is_cache. Има всичконяколко основни полета:
- код_собственика;
- код_сесии;
- h_code;
- a_surprise;
- a_contents.
Останалите полета носят обслужващи функции. Тази таблица стои на входа на всяка заявка и записва нейното пристигане. Какво ще работи моделът на базата данни се определя от неговия разработчик. Какво ще се побере в полето за съдържание (a_contents) се определя от обектите на модела, създаден от разработчика.
Има четири неща в тази идея: хит, сесия на посещения, код на историята на посещенията и конкретно съдържание. Какво е обаждане, каква система от обекти трябва да се изгради - се определя от разработчика. Какво се има предвид под сесия (работен процес) се определя от разработчика. Кодът на историята е възможността за връщане назад при заявки.
Таблиците тук нямат нищо общо с предметната област. Има контролер на повиквания (is_cache), има регистриране (is_customs), има история на обажданията (is_histories). Останалите таблици се определят от решаваната задача.
Всъщност това решение предлага да създадете свой собствен OODB въз основа на модела на базата данни на изградения домейн и проблема, който се решава. Тук има огромен плюс - това е вашата собствена концепция за данни, вашият собствен модел на тяхното представяне и връзката между тях. Тук има основа - страхотна релационна база данни. Няма да има проблеми да търсите нещо и да не разберете нещо.
Модел: обектна система + DBMS
Почти невъзможно е да се промени нещо в информационните технологии. Истинската информационна революция е все още далеч. професионално съзнаниеразработчиците на софтуер няма да променят класическите традиции. Но все още има изход от ситуацията.
Използвайки надеждни съвременни системи за управление на бази данни като основа за създаване на среда за съществуването на вашия собствен модел, можете да постигнете забележим успех.
Във всеки случай ще трябва да изградите изглед или модел на данни, за да решите задачата, но трябва да го направите правилно: нека това е система от обекти, а добрата СУБД да бъде нейната среда.
