Реферат: Об єктно-орієнтоване програмування

/etc/rc.d/init.d/kerneld start

Перезапуск не приводить до завантаження використовуваних у даний момент модулів, однак kerneld буде застосовувати збережену конфігурацію при запуску модулів у майбутньому.

У 1968 році компанія IBM запропонувала своїм клієнтам систему керування інформацією (IMS). Це була одна з перших спроб досягти хоча б деяких цілей підходу на основі баз даних до керування файлами й один з перших прикладів СУБД. У IMS база даних була концептуально представлена у виді ієрархії. Запису були організовані в набори, що зв'язувалися один з одним зв'язками володіння (ownership).

Ієрархічні бази даних підходять для тих інформаційних систем, що природним образом ґрунтуються на ієрархічній моделі. Істотним високопродуктивних великих систем, побудованих на основі IMS. Однак більшість систем неможливо реалізувати у виді IMS так, щоб уникнути великої кількості повторень даних.

У мережній моделі маються дві основні конструкції: запису і зв'язки. Зв'язок являє собою набір фізичних покажчиків, що задають відношення володіння між наборами записів. Так, можна сказати, що клієнт «володіє» набором замовлень, а деяке замовлення «володіє» набором елементів запасів (як і в ієрархічній моделі). Але в мережній моделі немає обмеження, що вимагає, щоб володіння задавалося тільки в одному напрямку, і набір записів може брати участь у довільному числі зв'язків володіння.

Використовуючи мережний підхід, можна шляхом ретельного аналізу даних усунути надмірність, і файли системи дійсно стануть інтегрованими. Але ця інтеграція досягається за рахунок складності. Мережні бази даних характеризуються великою кількістю наборів записів, кожний з який містить небагато інформації і багато покажчиків на інші безлічі записів. Навіть написання найпростіших запитів може зажадати складної навігації від одного набору записів до іншого.

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

У реляционной базі даних зв'язування даних різних таблиць один з одним здійснюється не за допомогою явних покажчиків (як у мережній базі даних), а за допомогою значень атрибутів.

У реляционной базі даних можна задавати зв'язку між будь-якими двома атрибутами, що мають порівнянні значення даних. Атрибут одного відношення, що складає винятково з числових значень, можна зв'язати з будь-яким атрибутом будь-якого іншого відношення, що складає також винятково з чисел. Таким чином, завдання логічних зв'язків між відносинами не становить труднощі.

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

Объективно-ориентированная технологія намагається перебороти ці обмеження. Схема объективно-ориентированной бази даних складається з колекції класів. Клас є колекцією об'єктів, причому структура і поводження об'єктів одного класу однакові. Видима структура об'єкта визначається властивостями його класу. Так у нашій гіпотетичній базі даних клієнт буде мати такі властивості, як номер, ім'я, адреса, статус і ін. Поводження об'єкта задається за допомогою методів його класу. Метод – це, по суті, деяка операція, яку можна застосувати до об'єкта. Він представляє те, що, по-нашому думки, повинний робити об'єкт. Наприклад, клієнт може створювати замовлення, оплачувати рахунок і т.д., отже, необхідні методи для кожного з цих видів діяльності.