Функцыянальная залежнасць і рэляцыйныя базы дадзеных

Інфармацыя заўсёды мела адэкватны дынамічны цікавасць. Развіццё моў праграмавання, рэляцыйных баз дадзеных і інфармацыйных тэхналогій кардынальна змяніла змест і структуру цікавасці. Склалася пэўная строгая сістэма ўяўленняў. Фармалізацыя, дакладная матэматыка і бінарныя адносіны сталі паспяховай і, імкліва развіваецца, вобласцю ведаў і вопыту.

Натуральны свет інфармацыі не памяняў сваёй дынамікі і, развіваючы змест і структуру, падняўся на новую вышыню. Ён мае плыўныя формы, і ў прыродзе няма нічога «прастакутнага». Інфармацыя, безумоўна, паддаецца фармалізацыі, але ў яе ёсць дынаміка, мяняюцца не толькі дадзеныя і алгарытмы іх апрацоўкі, змяняюцца самі задачы і вобласці іх прымянення.

Інфармацыя> фармалізацыя >> дадзеныя

Інфармацыя, ператвараецца ў дадзеныя (мадэль дадзеных, інфармацыйная структура, база дадзеных ...) так, як гэта бачыць праграміст. Няма ніякай гарантыі, што гэта бачанне правільна, але калі яго праграма вырашае пастаўленую задачу, значыць дадзеныя былі прадстаўлены магчыма належным чынам.

Пытанне аб тым, наколькі была правільна фармалізаваная інфармацыя - пытанне часу. Да гэтага часу паняцце дынамікі (самоадаптации да зменлівых умоў выкарыстання) - толькі толькі мара праграмавання.

Функцыянальная залежнасць: «правільнае рашэнне = праграма (праграміст)» і ўмова: «бесперапыннае адпаведнасць задачы» сапраўдныя на большасці выпадкаў, але толькі сумесна. Але гэта не тая матэматычная аснова, якая ўжываецца пры стварэнні баз дадзеных.

Прамое сцвярджэнне: натуральная і бесперапынная дынаміка інфармацыі і алгарытмаў вырашэння задач сапраўды заўсёды. А рэляцыйныя базы дадзеных гэта бінарныя адносіны + строгая матэматыка + дакладныя фармальныя канструкцыі, + ...

Дадзеныя, файлы і базы дадзеных

Як захоўваюцца дадзеныя ўжо даўно ўсё роўна: няхай гэта будзе аператыўная памяць ці вонкавая прылада. Апаратная складнік дасягнула упэўненых тэмпаў развіцця і забяспечвае добрае якасць у вялікіх аб'ёмах.

Асноўныя варыянты захоўвання, адрозныя варыянтамі выкарыстання дадзеных:

• файлы;
• базы дадзеных.

Першае аддадзена на водкуп праграмісту (што запісваць, у якім фармаце, як гэта рабіць, як чытаць ...), другое адразу прыносіць неабходнасць пазнання просты функцыянальнай залежнасці.

Хуткасць выбаркі і запісы інфармацыі пры працы з файламі (разумнага памеру, а не астранамічнага) вельмі хуткая, а хуткасць аналагічных аперацый з базай дадзеных можа часам быць прыкметна павольнай.

Асабісты вопыт і калектыўны розум

У гісторыі былі спробы выйсці за дасягнутыя межы, але па гэты дзень пануюць рэляцыйныя базы дадзеных. Назапашаны вялікі тэарэтычны патэнцыял, практыка прымянення шырокая, а распрацоўшчыкі - высокакваліфікаваныя.

Паняцце функцыянальнай залежнасці распрацоўшчыкі баз дадзеных навязваюць праграмісту, нават калі той не мае намеру выкарыстоўваць багаты матэматычна-лагічны вопыт пабудовы складаных інфармацыйных структур, працэсаў працы з імі, выбаркі і запісы інфармацыі.

Нават у самым простым выпадку праграміст залежыць ад логікі базы дадзеных, якую б ён ні абраў для працы. Няма жадання прытрымлівацца канонах, можна выкарыстоўваць файлы, атрымаецца шмат файлаў і шмат асабістага вопыту. Будзе выдаткавана шмат асабістага часу і задача будзе вырашана за доўгі час.

Якімі б складанымі ні здаваліся прыклады функцыянальнай залежнасці, зусім не абавязкова апускацца ў глыбіні сэнсу і логікі. Часта варта прызнаць, што калектыўны розум здолеў стварыць выдатныя базы дадзеных, рознага памеру і функцыянальнасці:

• салідны Oracle;
• патрабавальны MS SQL Server ;
• папулярны MySQL.

- выдатныя рэляцыйныя базы дадзеных з добрай рэпутацыяй, зручныя ў выкарыстанні, хуткія ва ўмелых руках. Іх ужыванне эканоміць час і пазбаўляе ад неабходнасці пісаць чарговыя прасціны дапаможнага кода.

Асаблівасці праграмавання і дадзеных

У праграмавання з даўніх часоў хвароба нешта пастаянна перапісваць, паўтараць працу папярэднікаў, каб як-небудзь што-небудзь адаптаваць да якая змянілася інфармацыі, задачы або ўмовамі яе выкарыстання.

Асаблівасць функцыянальнай залежнасці ў тым, што, як і ў праграмаванні, памылка можа каштаваць вельмі дорага. Задача рэдка бывае просты. Звычайна, у ходзе фармалізацыі інфармацыі, атрымліваецца складанае паданне дадзеных. Звычайна вылучаюцца іх элементы, потым яны ўвязваюцца ключамі ў пэўныя адносіны, потым наладжваюцца алгарытмы фарміравання табліц, запыты, алгарытмы выбаркі інфармацыі.

Часта вялікае значэнне мае прывязка да кадоўцы. Не ўсе базы дадзеных прапануюць мабільныя рашэнні, часта можна сутыкнуцца з тым, як выдатна наладжаны MySQL, на якім ляжыць дзесятак баз дадзеных, выдатна і стабільна працуе, змушае распрацоўніка рабіць адзінаццатую базу падобнай тым, якія ўжо ёсць.

Бываюць выпадкі, калі агульны хостынг абмяжоўвае функцыянальнасць PHP і гэта накладае адбітак на праграмаванне доступу да базы дадзеных.

У сучасным праграмаванні адказнасць за алгарытм праграмы эквівалентная адказнасці за стварэнне мадэлі дадзеных. Усё павінна працаваць, але не заўсёды варта апускацца ў нетры тэорыі.

БД: простая залежнасць ў дадзеных

Перш за ўсё, паняцце БД - гэта і база дадзеных як сістэма кіравання базамі дадзеных (напрыклад, MySQL), так і нейкая інфармацыйная структура, якая адлюстроўвае дадзеныя задачы і сувязі паміж імі. Адна база MySQL «трымае» на сабе колькі заўгодна інфармацыйных структур па розных сферах прымянення. Адна база Oracle, можа забяспечваць інфармацыйныя працэсы буйной кампаніі або банка, кантраляваць пытанні бяспекі і захаванасці дадзеных на вышэйшым узроўні, размяшчаючыся на мностве кампутараў, якія знаходзяцца на розным выдаленні, у розных інструментальных асяроддзях.

Прынята лічыць, што стаўленне ёсць асноўнае ў рэляцыйнай мадэлі. Элементарнае стаўленне - гэта мноства калонак з імёнамі і радкоў са значэннямі. Класічны «прастакутнік» (табліца) - простае і эфектыўнае дасягненне прагрэсу. Складанасці і функцыянальная залежнасць базы дадзеных пачынаюцца, калі «прастакутнікі» пачынаюць ўступаць у адносіны адзін з адным.

Імя кожнай калонкі ў кожнай табліцы павінна быць унікальным у кантэксце задачы. Адно і тое ж гэта не можа быць у двух табліцах. Ведаць сэнс паняццяў:

• «Вызначыць сутнасці»;
• «Выключыць надмернасць»;
• «Зафіксаваць ўзаемасувязі»;
• «Забяспечыць дакладнасць».

- элементарная неабходнасць для выкарыстання базы дадзеных і пабудовы мадэлі дадзеных для канкрэтнай задачы.

Парушэнне любога з гэтых паняццяў - нізкая эфектыўнасць алгарытму, павольная выбарка дадзеных, страта дадзеных, і іншыя непрыемнасці.

Функцыянальная залежнасць: логіка і сэнс

Можна не чытаць пра картэжы адносін, пра тое што функцыя - гэта адпаведнасць мноства аргументаў мностве значэнняў, а функцыя - гэта не толькі формула або графік, але можа быць зададзена мноствам значэнняў - табліцай.

Не абавязкова, але зусім не перашкодзіць прадстаўляць функцыянальную залежнасць як:

F (x1, x2, ..., xN) = (y1, y2, ..., yN).

Але абавязкова разумець, што на ўваходзе - табліца, на выхадзе таксама табліца або канкрэтнае рашэнне. Звычайна функцыянальная залежнасць ўсталёўвае логіку адносін паміж табліцамі, запытамі, прывілеямі, трыгерамі, захоўваемымі працэдурамі і іншымі момантамі (кампанентамі) базы дадзеных.

Звычайна, табліцы пераўтворацца сябар у сябра, потым у вынік. Але выкарыстанне функцыянальнай залежнасці не абмяжоўваецца толькі такой ідэяй. Праграміст сам будуе сваё ўяўленне карціны дадзеных, мадэлі прадметнай вобласці, інфармацыйнай структуры ... усё роўна, як гэта называць, але калі яно працуе на канкрэтнай базе дадзеных, яно павінна будавацца па яе логіцы, улічваць яе сэнс і дыялект выкарыстоўваемай мовы, як правіла, SQL.

Можна сцвярджаць, што ўласцівасці функцыянальных залежнасцяў базы дадзеных даступныя праз дыялект выкарыстоўваемай мовы SQL. Але значна важней разумець: пасля ўсіх перыпетый развіцця, не так шмат баз дадзеных выжыла, але дыялектаў гэтай мовы шмат і асаблівасцяў ўнутраных канструкцый у базах таксама.

Аб старым добрым Excel

Калі кампутар паказаў сябе са станоўчага боку, свет адразу падзяліўся на праграмістаў і карыстальнікаў. Як правіла, першыя выкарыстоўваюць:

• PHP, Perl, JavaScript, C ++, Delphi.
• MySQL, Oracle, MS SQL Server, Visual FoxPro.

другія:

• Word.
• Excel.

Некаторыя карыстальнікі прымудраўся рабіць самастойна (без дапамогі праграмістаў) у Word базы дадзеных - рэальны нонсэнс.

Досвед працы карыстальнікаў у Excel па стварэнні баз дадзеных - практычны і цікавы. Важна тое, што Excel, сам па сабе, функцыянальны, маляўнічы і практычны.

Таблічная ідэя, вызначыла паняцце функцыянальнай залежнасці наглядна і даступна, але нюансы ёсць у кожнай базы дадзеных. У кожнай свой "твар", але усё, што ад Excel да Oracle маніпулююць простымі квадратамі, то ёсць табліцамі.

Калі ўлічыць, што Excel - гэта зусім ня база дадзеных, але многія юзэры (не праграмісты) яго менавіта так выкарыстоўваюць, а Oracle - гэта найскладанае і наймагутнае дасягненне вялікага калектыву распрацоўшчыкаў менавіта ў галіне баз дадзеных, то становіцца натуральным прызнаць - база дадзеных гэтае паданне канкрэтнага праграміста (калектыву) аб канкрэтнай задачы і яе рашэнні.

Што такое функцыянальная залежнасць, з чым, куды, чаму ... відавочна толькі аўтару або калектыву такіх.

Пра тое, куды рэляцыйныя адносіны ідуць

Навукова-тэхнічны прагрэс - вельмі пакутлівая працэдура, а месцамі жорсткая. Калі ўспомніць з чаго пачыналіся базы дадзеных, што такое * .dbf, як таўравалі кібернетыку, потым палюбілі інфарматыку і сталі ўладкоўваць перашкоды перамяшчэнню высокіх тэхналогій на ўзроўні краін, становіцца зразумела чаму рэляцыйныя базы дадзеных так жывучыя і добрыя. Чаму класічны стыль праграмавання па сённяшні дзень жыве, а аб'ектна-арыентаванае праграмаванне проста цэніцца, але яшчэ не пануе.

Як бы ні была выдатная функцыянальная залежнасць у кантэксце матэматыкі:

Гэта не бінарныя адносіны, дакладней, гэта падстава пераасэнсаваць ідэю ўсталёўваць адносіны паміж мноствам атрыбутаў, даследаваць сувязі «адзін да шматлікім», «многія да аднаго», «многія да многіх» або «многія ўвогуле, а адны ў прыватнасці».

Варыянтаў адносінаў можна прыдумаць вялікае мноства. Гэта матэматыка з логікай, і яна строгая! Інфармацыя - гэта свая матэматыка, асаблівая. У ёй пра фармальнасці можна казаць толькі з вельмі вялікім мінусам.

Можна фармалізаваць працу аддзела кадраў, напісаць АСК для здабычы нафты або вытворчасці малака, хлеба, зрабіць выбарку ў велізарнай базы гугла, яндэкса або Рамблера, але вынік будзе заўсёды статычны і кожны момант часу аднолькавы!

Калі функцыянальная залежнасць = строгая логіка і матэматыка = аснова для баз дадзеных, то пра якую дынаміку можна весці гаворку. Любое рашэнне будзе фармальным, любая фармальная мадэль дадзеных + строгі алгарытм = дакладнае і адназначнае рашэнне. Інфармацыя і вобласць прымянення любой праграмы змяняюцца заўсёды.

Выбарка пошукавай сістэмы на адной і той жа пошукавай фразе не можа быць адной і той жа праз гадзіну ці праз два і, адназначна, праз дзень - калі пошукавая фраза ставіцца да вобласці інфармацыі, у якой колькасць сайтаў, рэсурсаў, ведаў, іншых элементаў бесперапынна мяняецца .

Аб радках і аб'ектах

Нават калі праграма чыста матэматычная і яе база дадзеных нават не думае пра дынаміку, усё заўсёды ёсць радкі. А ў радка ёсць доўгая. І бясконцай яна быць не можа. Яна не можа быць нават зменнай, толькі ўмоўна-зменнай. Акрамя ўсяго іншага, любая база дадзеных сваім матэматычным і бінарным-бюракратычным апаратам накладвае масу фармальнасцяў, а гэта хуткасць + якасць выбаркі і апрацоўкі інфармацыі.

строки условно-переменной длины с массой бинарных формальностей и строгих математических ограничений. А калі тыя ці іншыя поля ў базе дадзеных колькасці, асабліва рэчавыя то ў абмежаванні дададуцца: разраднасць колькасці, наяўнасць літары "е", фармату прадстаўлення - карацей усюды і заўсёды маем важныя ўласцівасці функцыянальных залежнасцяў базы дадзеных: радкі ўмоўна-зменнай даўжыні з масай бінарных фармальнасцей і строгіх матэматычных абмежаванняў.

Калі змяніць тон і прыслухацца да пульса дынамікі, то ўсё можна распісаць на аб'екты. У першым набліжэнні імя калонкі ў табліцы - гэта аб'ект, спіс імёнаў - таксама аб'ект, карацей табліца - гэта аб'ект шапкі і ў ім імёны калонак у шапцы. І шапкі можа зусім не быць ...

Але ў табліцы могуць быць радка. І ў радку могуць быць значэння. І чаму іх заўсёды павінна быць аднолькавая колькасць. Поўная квадратная табліца - гэта прыватнасць, прычым у большасці выпадкаў, прыватная.

Калі ўявіць усе канструкцыі ў базе дадзеных аб'ектамі, то, быць можа, не прыйдзецца выбудоўваць строгія бінарныя адносіны. У гэтым ёсць натуральны і рэальны сэнс хоць бы таму, што гэта па аб'ектыўнай (адназначна ня матэматычнай) логіцы адлюстроўвае дынаміку інфармацыі і асяроддзя, у якой існуюць задачы.