АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция

Передумови виникнення систем управління базами даних

Читайте также:
  1. FIDELIO V8 - новое поколение систем управления для гостиниц
  2. III. Лексика как система (8 часов)
  3. L.1.1. Однокомпонентные системы.
  4. L.1.2.Многокомпонентные системы (растворы).
  5. S: Минимальный налог при упрощенной системе налогообложения - это
  6. SCADA как система диспетчерского управления
  7. SCADA как часть системы автоматического управления
  8. SCADA система Citect
  9. SCADA системы как инструмент проектирования АСУ ТП
  10. SCADA системы. Обзор SCADA систем
  11. SCADA-система: назначение и функции
  12. SCADA: требования к системам верхнего уровня

На ранній стадії впровадження і використання інформаційних систем у комерційної діяльності домінувала файлова модель обробки та позадачний підхід. Незважаючи на те, що файлові системи[9] вже застаріли, знати принципи їх роботи дуже корисно.

Файлові системи були першою спробою комп¢ютеризовати відомі всім ручні картотеки. Така картотека (або підшивка документів) в будь-якій організації може містити як зовнішню так і внутрішню інформацію, що пов¢язана з якимось проектом, задачею або функцією. Найбільш відомий варіант таких картотек – це документи, пов¢язані з особистими справами кожного робітника у відділі кадрів будь-якої організації. Такі особисті справи зберігаються в одному чи декількох шафах. Якщо вам потрібно знайти якусь інформацію потрібно проглянути всі документи (особисті справи) від початку до кінця. Для полегшення виконання таких функцій кадрової служби створюються картотеки, в яких основна інформація по кожній особі з особистої справи заноситься на картку (наприклад, на основі картки форми Т2). Тоді, замість перегляду всіх особистих справ, досить проглянути тільки картотеку (якщо потрібна інформація занесена до карток). Ручні картотеки дозволяють з успіхом виконувати пошукові операції, якщо кількість екземплярів карток невелика.

Застосування комп¢ютерної техніки дозволяє суттєво прискорити всілякі пошукові процеси, тому файлові системи були розроблені у відповідь на потребу отримати більш ефективних засобів доступу до даних. Спочатку основним механізмом пам¢яті була магнітна стрічка (з додатковим запасом перфокарт та перфострічок). У зв¢язку з її послідовною природою використовувалася стандартна модель обробки, що побудована на основі майстер-файлів та файлів транзакцій (мал. 13).

Наприклад, майстер-файл у кадровій автоматизованій інформаційній системі являє собою сукупність послідовних записів, що відображають інформацію по кожному студенту, який вчиться у вищому навчальному закладі. Кожний запис містить ідентифікаційний номер, прізвище, ім¢я, по-батькові, дата народження, рік вступу у ВУЗ тощо. При поповнення ВУЗу

 
 

 

 


Мал. 13. Взаємодія стрічкових майстер-файлу та файлу транзакцій у файловій інформаційній системі

 

в черговому наборі формується (готується інформація по прийнятим студентам) файл транзакцій, який при послідовній обробці формує новий стан кадрової інформації по наяв­ним студентам, також відсортований по ідентифікаційним номерам. Програмне забезпе­чен­ня (написане на загальних мовах програмування – Коболі, PL/1 тощо) повинно мати у своєму тілі програм опис структури запису майстер-файлу з локалізацією окремих елементів даних в запису, та їх атрибутів. Стрічковий спосіб збереження інформації для виконання функцій обробки кадрової інформації при автоматизації функцій по пошуку та веденню інфор­мацій­ної бази з персоналу вимагав від спеціалістів чіткої регламентації своїх дій та їх узгодження з технологією комп¢ютерної обробки інформації в обчислювальних центрах, яка мала специфічні етапи для підтримки процедур захисту інформації від жорстких збоїв (копіюван­ня по технології “дід – батько – син” тощо).

При появі засобів пам¢яті безпосереднього доступу, такої, як магнітні диски, з¢явилася можливість застосування нової моделі обробки ділової інформації. Попередньо дисководи використовувалися як замінники стрічкових накопичувачів файлів, але потім застарілі застосування були витіснені, а стали загальноприйнятими моделі взаємодії із заміщенням. При цьому транзакції застосовувалися безпосередньо до майстер-файлів без послідовної обробки і створення нового покоління майстер-файлів.

З середовищами застосувань, що основані на файлах, були пов¢язані ряд проблем. Головна з них заключалася у протиріччі ієрархічної природи предметних областей з послідовним представленням їх у записах файлів. Наприклад, в інформації по студентам повинна була відображена їх дані про попередню участь у роботі чи навчанні в різних організаціях (школа, технікум, робота тощо) (див. мал. 14).

Крім того, моделі, що використовувалися більшістю операційних систем для доступу до файлів даних та їх блокування, робили одночасне використовування застосувань в найкращому випадку ненадійним, а в багатьох випадках майже неможливим. Саме з цими проблемами пов¢язана поява ранніх поколінь систем управління базами даних.

Хоча багато різних архітектур конкурували за перевагу на ранній стадії “баз даних” чи “банків даних” (термін, який вже більше не вживається), найпершою найбільш поширеною комерційною системою була СУБД IMS (Information Management System)

 

Номер ПІБ Місто група телефон курс
  Аксент¢єв В.А. Київ МІС-83/3    
  Вікторов А.С. Полтава МІС-82/33    
  Лобунець О.О. Донецьк СК-25    

 

Мал. 14. Структура записів інформації по студентам у файловій системі

 

фірми IBM [10] з її ієрархічною моделлю даних та мовою баз даних DL/1. Оскільки фірма ІВМ у 60-ті роки домінувала на ринку великих обчислювальних систем, у багатьох застосуваннях почали використовувати для роботи з базами даних мови Кобол та DL/1.

Ієрархічна модель взагалі і бази даних IMS зокрема реалізовані засобами древовидних структур з коріневими сегментами, що мають фізичний покажчик на інші сегменти. Іншим досягненням середини 60-х років була поява системи IDS (Integrated Data Store) фірми General Electric. Розвиток цієї системи призвело до створення нового типу системи управління базами даних – сітьових (мережевих) СУБД, - що також виявило суттєвий вплив на інформаційні системи того покоління.

Сітьова СУБД створювалася для представлення більш складних взаємозв¢язків між даними, ніж ті, що моделювалися за допомогою ієрархічних структур. Але все одно цим двом моделям були присутні наведені нижче недоліки:

· для виконання простих запитів з використанням переходів і доступу до визначених записів необхідно було створювати досить складні програми;

· незалежність даних існувала лише в малій ступені;

· відсутність загальноприйнятих теоретичних засад.

В 1970 році Е.Ф.Кодд, який працював в дослідній лабораторії корпорації ІВМ, опублікував досить важливу і своєчасну статтю о реляційній моделі даних, що дозволяє усунути недоліки попередніх моделей. Слідом за цим з¢явилося багато експериментальних -реляційних СУБД, а перші комерційні продукти з¢явилися у кінці 70-х – на початку 80-х років. Особливо треба відмітити проект System R, що був розроблений у дослідній лабораторії корпорації ІВМ, що розташована в м. Сан-Хосе, штат Каліфорнія, створений у кінці 70-х років (Astrahan). Він був замислений з метою обгрунтувати практичність реляційної моделі, що досягалося за допомогою реалізації передбачених нею структур даних і вимагаємих функціональних можливостей. На основі цього проекту були отримані найважливіші результати:

· була розроблена структурована мова запитів, яка потім стала стандартною мовою будь-яких реляційних (і нереляційних) СУБД;

· у 80-х роках були створені різноманітні комерційні СУБД – наприклад, DB2 чи SQL/DS корпорації ІВМ чи Oracle корпорації Oracle Corporation.

В наступний час існує кілька сот різноманітних реляційних СУБД для мейнфреймів та мікрокомп¢ютерів, хоча для більшості з них визначення реляційної моделі носить декілька перебільшений характер. В якості прикладів багатокористувацьких СУБД можуть бути розглянуті такі СУБД, як Informix фірми Informix Software Inc., Oracle та DB2, а для ПЕОМ такі СУБД як Access та FoxPro фірми Microsoft.

Але реляційна модель також володіє деякими недоліками, зокрема, обмеженими можливостями моделювання. Тому, для вирішення цієї проблеми у 1976 році Чен запропонував модель " сутність - зв¢язок ” (Entity – Relationship modelER-модель), яка стала найбільш поширеною в наступний час технологією проектування баз даних. Потім, у відповідь на все більше зростання складності застосувань, почали запропоновуватися об¢єктно-орієнтовані моделі баз даних, але поки що дійсна структура таких моделей не зовсім ясна.


1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 |

Поиск по сайту:



Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.004 сек.)