Створена методична інструкція не претендує ні на що. Можливо існує інший (простіший, надійніший, швидший та ін.) шлях встановлення Dspace. Прошу пишіть та створюйте конкуренцію. У методичці наводяться основні кроки по встановленню Dspace, вони не описані, також тут нема опису додаткових можливостей ПЗ яке забезпечує працездатність Dspace. Якщо у Вас виникли якісь розумні запитання чи пропозиції щодо розширення цієї методички, зауваження щодо змісту чи Вам просто важко у душі - пишіть на е-мейл: oai@lp.edu.ua . Також відкрився перспективний бібліотечний портал за адресою http://library.ridne.net ¬– приєднуйтесь, беріть участь у обговоренні проблем бібліотеки, проблем інформатизації бібліотеки та інше що пов’язане з бібліотекою. Щиро Ваш Андрухів Андрій.
Гендерный дисбаланс. Марина Комиссарова
Вимоги до встановлення:
а) Комп’ютер;
б) Людина з базовими знаннями UNIX, LINUX систем;
в) Internet.

1. Встановлюємо FreeBSD 7.2;
2. Для редактування файлів конфігурації та для спрощення роботи в ОС спочатку встановимо файловий менеджер Midnight Commander (MC). Для цього переходимо у файл з портами: # cd /usr/ports/misc/mc. Виконуємо команду: # make install clean. Якщо Інтернет проходить через проксі сервер то у файлі .cshrc додаємо стрічку setenv HTTP_PROXY ip_address:port. Додати цю стрічку можна через текстовий редактор VI. Для цього виконуємо наступні дії: # vi .cshrc .В результаті ми потрапимо у середовище VI. Для вводу стрічки, що пропише параметри проксі натиснемо клавішу Іш (Input) та вводимо setenv HTTP_PROXY ip_address:port. Після закінчення вводу натискаємо клавішу Esc. Для збереження результату натиснемо комбінацію :wq. Це дозволило вийти з редактора VI зі збереженням файлу. Перезавантажуємо комп’ютер.

2. Перекомпіляція ядра

Створена методична інструкція не претендує ні на що. Можливо існує інший (простіший, надійніший, швидший та ін.) шлях встановлення Dspace. Прошу пишіть та створюйте конкуренцію. У методичці наводяться основні кроки по встановленню Dspace, вони не описані, також тут нема опису додаткових можливостей ПЗ яке забезпечує працездатність Dspace. Якщо у Вас виникли якісь розумні запитання чи пропозиції щодо розширення цієї методички, зауваження щодо змісту чи Вам просто важко у душі - пишіть на е-мейл: oai@lp.edu.ua . Також відкрився перспективний бібліотечний портал за адресою http://library.ridne.net ¬– приєднуйтесь, беріть участь у обговоренні проблем бібліотеки, проблем інформатизації бібліотеки та інше що пов’язане з бібліотекою. Щиро Ваш Андрухів Андрій.

Вимоги до встановлення:
а) Комп’ютер;
б) Людина з базовими знаннями UNIX, LINUX систем;
в) Internet.

1. Встановлюємо FreeBSD 7.2;
2. Для редактування файлів конфігурації та для спрощення роботи в ОС спочатку встановимо файловий менеджер Midnight Commander (MC). Для цього переходимо у файл з портами: # cd /usr/ports/misc/mc. Виконуємо команду: # make install clean. Якщо Інтернет проходить через проксі сервер то у файлі .cshrc додаємо стрічку setenv HTTP_PROXY ip_address:port. Додати цю стрічку можна через текстовий редактор VI. Для цього виконуємо наступні дії: # vi .cshrc .В результаті ми потрапимо у середовище VI. Для вводу стрічки, що пропише параметри проксі натиснемо клавішу Іш (Input) та вводимо setenv HTTP_PROXY ip_address:port. Після закінчення вводу натискаємо клавішу Esc. Для збереження результату натиснемо комбінацію :wq. Це дозволило вийти з редактора VI зі збереженням файлу. Перезавантажуємо комп’ютер.

2. Перекомпіляція ядра

У березні вийшла у світ нова версія безкоштовної відкритої електронної системи управління електронним репозитарієм Dspace 1.5 . Попередньою версією була Dspace 1.4.2. Перші труднощі, які виникають із встановленням системи це зміна послідовості компіляції коду та тепер обов"язковим повинна бути наявність Інтернету. Після компіляції та встановлення Інтернет не є обов"язковим для роботи системи. Був трохи змінений і дизайн. Мною були розроблені детальні методичні вказівки щодо встановлення системи на оперційну систему FreeBSD 7.0 . Тому якщо в когось виникали труднощі із встановленням - прошу звертатись. Контакти наведені на http://it.ridne.net/user/123

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

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

Існує три основні методи інтеґрації даних: консолідація, федералізація і розповсюдження.

Консолідація даних – це збирання даних з територіально віддалених або різноплатформенних джерел даних в єдине сховище даних з метою їх подальшого опрацювання та аналізу.

У середовищі сховищ даних однією з найпоширеніших технологій підтримки консолідації є технологія ETL (витягання, перетворення і завантаження – extract, transform, and load). Ще одна поширена технологія консолідації даних ECM - керування змістом корпорації (enterprise content management). Більшість рішень ECM напрямлені на консолідацію і керування неструктурованими даними, такими як документи, звіти і web-сторінки.

Федералізація даних забезпечує єдину віртуальну картину одного або декількох первинних файлів даних. Процес федералізації даних завжди полягає у витяганні даних з первинних систем на підставі зовнішніх вимог. Всі необхідні перетворення даних здійснюються при їх витяганні з первинних файлів. Прикладом федералізації є інтеґрація корпоративної інформації (EII).

Багатовимірна база даних – база даних, що підтримує багатовимірну модель даних на концептуальному рівні та призначена для інтерактивного аналітичного опрацювання аґреґованих історичних і проґнозованих даних.

Основними поняттями багатовимірної моделі даних є:

Гіперкуб даних містить один або більше вимірів і є впорядкованим набором комірок. Кожна комірка визначається одним і лише одним набором значень вимірів – атрибутів. Комірка може містити дані – значення або бути порожньою.

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

Для отримання доступу до даних користувачу необхідно вказати одну або декілька комірок шляхом вибору значень вимірів, яким відповідають необхідні комірки. Процес вибору значень вимірів називатимемо фіксацією атрибутів, а множину вибраних значень вимірів – множиною фіксованих атрибутів.

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

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

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

Дослідники часу розрізняють два способи його подання: порядковий та структурний. Порядковий спосіб передбачає подання часу за допомогою натуральних чисел. Структурний спосіб ґрунтується на понятті структурування.
Розглянемо скінченну множину , на якій задане відношення порядку. Тобто .
Структуруванням множини називається пара , де , і – бієктивне відображення, яке кожному елементу множини ставить у відповідність скінченний закритий інтервал множини , причому:
1. .
2. .
Часовим універсумом називається скінченна множина , де – часові домени, – відображення, яке ділить (структурує) множину на блоки (інтервали) елементів, що відповідають елементам множини .
Відображення часового універсуму фактично задають календарну систему часу. Кожна предметна область визначає часовий універсум.

Час – це безмежна щільна множина елементів, на якій визначено відношення порядку. Ця множина є ізоморфною до множини дійсних чисел, тобто часова вісь подається як вісь дійсних чисел. Таке визначення належним чином відображає усі аспекти часу як одного з елементів дійсності.
В області баз даних часову вісь визначають як зліченну дискретну множину, на якій задано відношення порядку (“менше рівне”). Елементи цієї множини називаються часовими моментами.

Рис. 1. Часова вісь.
На рис. 1 зображено часову вісь з дискретними моментами часу. Причому:


Дискретна часова вісь ізоморфна до множини натуральних чисел.

http://pzhe.net/ua/tdb/time_mathdef

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

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

Як відомо, для зберігання та опрацювання даних використовують різні засоби: бази даних, сховища даних, оперативні сховища даних. Дамо визначення цих понять та здійснимо їх характеристику.

Наведемо декілька найбільш поширених визначень бази даних (БД).

База даних – сукупність екземплярів різних типів записів і відношень між записами та елементами.

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

Використання бази даних припускає роботу з нею декількох прикладних програм (застосувань), що вирішують завдання різних користувачів.

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

При аналізі та пошуку вразливих місць у програмах використовується кілька підходів. В даному випадку я наведу найпростіший. Схема роботи буде проста як двері. Компанія Rational створила програму Purify для динамічного дослідження програмного забезпечення. Ось її і будемо використовувати. За допомогою програми Hailstorm запускаємо процес внесення помилок у SQL Server 7 і за допомогою Purify будемо відслідковувати стан програми. Враховуючи, що у даному СУБД більше помилок, ніж стрічок з програмним кодом, використаємо хоча б одну з них. Наприклад, при внесенні некоректних даних в пакет протоколу SQL Server виникає проблема затирання даних в пам’яті. Збій проходить в результаті неправильної обробки даних. SQL сервер приймає запити по 1443 порту. Для цього порту жодних специфікацій не існує. Направимо на цей порт випадкові дані( нехай це будуть згенеровані цифри) з інтенсивністю 20 пакетів в секунду. SQL Server буде сприймати ці пакети без жодних проблем. Вхідні дані обробляються різними фрагментами коду. Фактично ці фрагменти виконують читання заголовків протоколу. Через деякий час Purify вкаже на виникнення помилки і на зміну даних у пам’яті. Такого роду помилка призводить до відмови в роботі сервера. І як результат нашої роботи ми отримаємо звіт програми Heilstorm, а програма Purify вкаже на точне місце в програмному коді, де міститься помилка. Як використовувати цю помилку вже залежить не від мене. Якби мені довелось б піти іншим шляхом ( наприклад, вводяться в програму дані і досліджується фрагмент коду, що відповідає за обробку цих даних) напевне це зайняло б у мене кілька днів. Наведений метод є ефективний хіба для продуктів мікрософту, де помилка помилку поганяє. Для нормального програмного забезпечення існують складніші методи та підходи до взламування.

Якось вчора так склалось життя, що довелось мені згадувати своє раннє дитинство і встановлювати сервер FreeBSD 6.1 . От ніби і в садок ходив, і в школі вчився, але після встановлення MYSQL 4.0.25 не міг його запустити. Встановив потім 5 версію – те саме. А в принципі, судячи із відгуків різних маньяків 4-й MYSQL працює значно стабільніше. Я ще зі свого народження підсів на нього і на 5-й ще переходити не збираюсь. В матеріалі мова піде про те, що мені довелось пережити щоб підняти MYSQL.
А почну із того, що встановлював я не з портів. Після встановлення спершу потрібно залізти у /usr/local/share/mysql і знайти 3 файли : mysql-small.cnf , mysql – medium.cnf, mysql-large.cnf . Як сі можна здогадати це типові конфігураційні файли для MYSQL . З назви видно, що кожен містить налаштування в залежності від схеми використання СУБД. Я особисто, вибрав 2-й файл та перейменував його у my.cnf. Щоб ці налаштування зробити глобальними потрібно скопіювати файл у /etc. Далі, через текстовий редактор проглядаємо налаштування. Єдине, що потрібно там змінити, так це розкоментувати стрічки: log-bin=mysql-bin; server-id=1. Ці стрічки відповідають за схему використання серверу – master чи slave. В даному випадку я визначив використання MYSQL у master режимі. Починаючи з freebsd 5 сокет mysql розміщений у файлі /tmp, тому його потрібно відкрити для запису(chmod 777 /tmp). Заходимо у /etc/rc.conf і прописуємо стрічку mysql_enable=”YES”( це автоматичний запуск СУБД після перезавантаження). Ну і в кінці потрібно змінити власника /var/db/mysql ( chown –R mysql:mysql /var/db/mysql). При встановленні MYSQL створюється користувач mysql та група до якої він належить mysql . Коли ми створюємо базу даних, то відповідно створюється файл з такою ж назвою ( поняття каталога у freebsd не існує!) у /var/db/mysql. Оскільки mysql запускається під користувачем mysql, то він повинен мати права на запис у цей файл. Перезавантажуємся і працюємо в СУБД. В даному матеріалі я упустив ті ерори , що видавала мені система і ті матюки, які я давав їй у відповідь. Фактично у таких випадках весь аналіз здійснюється по логах, які формує система. MYSQL записує всі свої помилки у /var/db/mysql/.err. Я вже близько року бавлюся із серверами і найгірше, те що не існує повноціного матеріалу, який би дозволив побувати сервер. Офіційна документація тільки до якогось демона зазвичай складає кілька десятків сторінок і не завжди є час її читати. Ще літом в мене виникла ідея написання такої книжки, але мені просто ліньки це робити, а особливо набирати. Тому шукаю привабливу дівчину, котра б могла це для мене зробити

Різні СКБД по різному виконують ідентичні SELECT-запити, записані за допомогою різних конструкцій.

Наступні два запити є ідентичні за результатом

Одна з переваг версії Oracle 9i (v.9.0.1) над попередніми полягає в підтримці ANSI стандарту SQL. Зокрема, Oracle 9i “нарешті” підтримує такі конструкції з’єднань, як
ТаблA INNER|LEFT|RIGHT|FULL JOIN ТаблB ON умова_з’єднання

Нещодавно вийшла у світ нова версія СКБД PostgreSQL - 8.0 (www.postgresql.org)

Особливістю версії є повна підтримка Windows-NT платформ - Win2000, XP, Win2003 (Win-95,98,ME не підтримуються). Попередні версії PostgreSQL повноцінно працювали на платформах UNIX/Linux, а у Windows-системах лише в режимі емуляції Cygwin для UNIX.

PostgreSQL - повністю безкоштовна система керування базами даних, яка підтримує загально поширені стандарти SQL. Мовою програмування процедур та функцій виступає варіант PL/SQL - PGPL/SQL.

PostgreSQL може сильно конкурувати з MS SQL-Server в якості сервера бази даних для корпоративних систем.

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

Може комусь це видасться банальним, але напишу пару слів про архів WWW.
Кілька раз за останній час стикався з тим, що навіть користувачі Інтернету зі стажем не знають про такий цікавий та корисний ресурс як http://www.archive.org - архів WWW.
На цьому сервері можна знайти старі копії сайтів. Сайти там представлені досить добре, в архів заносяться копії з інтервалом в кілька місяців.

Особливо корисним архів може бути в таких випадках

• Підтвердження авторства матеріалів (точніше першості публікування в Інтернет)
• Доступ до вже не існуючих сайтів чи сторінок.

Новина про систематичне викачування службових баз даних Державної автоінспекції уже трішки нашуміла. Почитати можна тут: http://www.korrespondent.net/main/101947

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

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