Размещено на http://www.allbest.ru/

ЗМІСТ

• ВСТУП
• 1. СТРАТЕГІЯ АВТОМАТИЗАЦІЇ ПРЕДМЕТНОЇ ОБЛАСТІ
• 1.1 Загальні положення
• 1.2 Мета, цілі та задачі створення бази даних
• 1.3 Вимоги до інформаційного забезпечення
• 2. АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ
• 2.1 Загальні положення системного аналізу ПО
• 2.2 Загальні положення соціальної мережі
• 2.3 Системний аналіз предметної області
• 3. КОНЦЕПТУАЛЬНЕ МОДЕЛЮВАННЯ ПРЕДМЕТНОЇ ОБЛАСТІ
• 3.1 Теоретичні положення концептуального моделювання
• 3.2 Мова ER--моделювання ПО
• 3.2 Побудова концептуальної моделі соціальної мережі
• 4. ЛОГІЧНЕ ТА ФІЗИЧНЕ ПРОЕКТУВАННЯ БАЗИ ДАНИХ
• 4.1 Логічне проектування
• 4.2 Фізичне проектування
• 4.2.1 Скрипти створення бази даних
• 4.2.2 SQL- скрипт заповнення початковими даними
• 4.2.3 Інформаційно-пошукові запити
• ВИСНОВКИ

ВСТУП

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

· розробка стратегії автоматизації предметної області;

· проведення системного аналізу предметної області;

· концептуальне моделювання предметної області;

· логічне та фізичне проектування.

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

Головною ціллю курсової роботі є проектування бази даних соціальної мережі на прикладі «facebook».

1. СТРАТЕГІЯ АВТОМАТИЗАЦІЇ ПРЕДМЕТНОЇ ОБЛАСТІ

1.1 Загальні положення

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

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

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

Основні результати цього етапу повинні включати:

· визначення цілей і завдань автоматизації;

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

· визначення границь системи, сфера застосування системи баз даних;

· можлива архітектура системи;

· вимоги до системи;

· поетапний план розробки.

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

1.2 Мета, цілі та задачі створення бази даних

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

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

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

Цілями створення бази даних є наступні:

· Підвищення ефективності та зручності ведення інформації про всіх користувачів соціальної мережі.

· Вдосконалення контролю надання користувачам інформації про конкретну особу. Встановлення налаштувань приватності.

· Надання узагальнюючої інформації за різними критеріями пошуку.

· Надання можливості обмінюватися повідомленнями, інформаційними ресурсами між користувачами.

Досягнення зазначених цілей виконується за рахунок:

· створення комплексної інформаційної системи із централізованою базою даних;

· підвищення вірогідності, несуперечності, повноти й надійності інформації;

· підвищення наочності, зручності використання й інформативності одержуваних даних.

1.3 Вимоги до інформаційного забезпечення

Проектні рішення з інформаційного забезпечення (ІЗ) повинні передбачати реалізацію концепції „відкритих систем”, тобто розширення функціональних можливостей системи без зміни існуючих елементів ІЗ. ІЗ повинно задовольняти умові можливої повноти. Інформаційне забезпечення системи повинно включати:

· систему класифікації і кодування;

· поза-машинну інформаційну базу (ІБ);

· внутрішньо-машинну ІБ.

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

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

Проектні рішення з розробки внутрішньо-машинної ІБ повинні відображати фізичний рівень зберігання інформації в системі у вигляді баз даних (БД) і масивів повнотекстової інформації та враховувати:

· розподілене збереження інформаційних ресурсів;

· динаміку актуалізації інформації;

· спосіб представлення та структуризацію інформації (реляційні БД, текстові файли, електронні документи і т. ін.).

БД має містити наступну інформацію:

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

· Інформація про налаштування приватності. Це сукупність інформації про обмеження перегляду даних власника сторінки для інших користувачів.

· Інформація про відношення між користувачами. Дана інформація містить відношення між парами користувачів (друг/недруг, закохані, зустрічаються, одружені, батьки/діти).

· Інформація про повідомлення. Це сукупність інформації про кожне повідомлення, надіслане конкретному користувачу, яка містить у собі інформацію про відправника, одержувача та сам текст повідомлення.

· Інформація про інформаційні ресурси (аудиозаписи, відеозаписи, зображення тощо).

БД повинна бути спроектована таким чином, щоб задовольняти вимогам щодо реакції системи на запити (1-5 секунди).

алгоритм мережа реляційний скрипт

2. АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ

2.1 Загальні положення системного аналізу ПО

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

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

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

· аналіз потоку користувачів;

· аналіз розв'язуваних в організації завдань і способів їхнього рішення;

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

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

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

· ретельна перевірка вірогідності, повноти, несуперечності отриманої інформації .

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

· точні об'ємно-частотні характеристики даних;

· твердий контроль за ходом робіт, повна концентрація зусиль на виконанні календарних планів і дотриманні запланованих строків.

2.2 Загальні положення соціальної мережі

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

Соціальна мережа має широкий спектр можливостей та прав для звичайних користувачів. Серед них можна відмітити такі:

· Можливість реєструватися;

· Можливість видалити данні про себе (сторінку);

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

· Можливість зв'язувати сторінки користувачів одним із можливих видів зв'язку (друзі, недруги). Для встановлення зв'язку підтвердження його повинні провести користувачі обох сторінок. Небажаних користувачів можна занести до так званого «чорного списку» і таким чином обмежити йому доступ до власних даних;

· Можливість завантажувати в систему інформаційні ресурси(аудіо, відео фали та зображення) і зв'язувати їх зі своєю власною сторінкою відношеннями: автор, присутній у інформаційному ресурсі;

· Можливість налаштувати зовнішній вигляд власної сторінки;

· Можливість писати повідомлення, а також надсилати інформаційні ресурси іншим користувачам;

· Можливість виконувати пошук в системі інших користувачів;

· Можливість налаштовувати свої власні «Налаштування приватності». За допомогою цих налаштувань можна обмежити доступ до своєї сторінки.

2.3 Системний аналіз предметної області

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

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

Бізнес-правила - це правила й обмеження, що діють у ПО відносно основних понять інформаційної структури (сутностей, атрибутів і зв'язків). Виділяються бізнес правила, що мають відносини до атрибутів однієї сутності (унікальність атрибутів, ідентифікація сутності, спеціальні правила), до зв'язків між сутностями (факультативність закінчення зв'язку, потужність закінчень зв'язку (1:1, 1:n, m:n), ступінь зв'язку).

Інформаційно-довідкові задачі (на відміну від прикладних задач) -- це ті задачі, які вибирають деяку підмножину даних з інформаційної моделі ПО.

Далі предметна область описується із вказівкою сутностей їхніх атрибутів, зв'язків і діючих бізнес-правил. Опис інформаційно-довідкових задач приводиться окремо.

У результаті аналізу ПО були визначені наступні сутності, їх атрибути та зв'язки:

2.3.1 Сутність «Користувач»

Сутність використовується для збереження особистої інформації користувача.

Атрибути:

· Електронна адреса

· Пароль, зашифрований із закритим ключем (алгоритм md5)

· Номер телефону

· Ім'я

· Прізвище

· Дата народження

· Стать

· Місце народження

· Логін Skype

· Уподобання

· Місто проживання

· Тип користувача

· Фото користувача

· Стан підтвердження електронної адреси

· Стан підтвердження номеру телефона

Зв'язки:

· У користувача може бути вказане одне місце народження

· У користувача може бути вказана одна адреса проживання

· Для користувача обов'язково повинен бути визначений тип користувача

· Для користувача може бути визначена його фотографія

· Для користувача можуть бути визначенні оподобання, місця та ін.

Бізнес-правила:

· Унікально ідентифікується електронною адресою або номером телефону

2.3.2 Сутність «Тип користувача»

Тип користувача - сутність-класифікатор, яка використовується для визначення можливостей та прав користувачів.

Атрибути:

· Назва

Зв'язки:

· Тип користувача - обов'язковий атрибут кожного користувача .

Бізнес-правила:

· Унікально ідентифікується назвою типу користувача

2.3.3 Сутність «Відношення»

Відношення - сутність, яка створена для того, щоб об'єднувати пари користувачів за їх бажанням відповідно до можливих типів відношень із сутності «Тип відношення»

Атрибути:

· Стан підтвердження відношення

Зв'язки:

· Перший користувач відношення - один зі елементів сутності «Користувач»

· Другий користувач відношення (не може співпадати із першим) - один зі елементів сутності «Користувач»

· Тип відношення повинен вибиратися із сутності «Тип відношення» і визначати відношення першого користувача до другого, а не навпаки

Бізнес-правила:

· Унікально ідентифікується трьома значеннями: перший користувач, другий користувач та тип відношення.

2.3.4 Сутність «Тип відношення»

Тип відношення - сутність-класифікатор, яка визначає, в яких відносинах знаходяться пари користувачів

Атрибути:

· Назва відношення

Зв'язки:

· Пара користувачів може перебувати тільки у одному із визначених видів відношень, наприклад, пара користувачів не може мати одночасно відношення друг і недруг, тому що вони суперечливі

Бізнес-правила:

· Унікально ідентифікується назвою типу відношення

2.3.5 Сутність «Країна»

Країна - сутність-класифікатор, яка використовується для ідентифікації зв'язку користувача з однією з країн світу.

Атрибути

· Назва

Зв'язки:

· Для одного користувача може бути визначена тільки одна країна народження та одна країна поточного проживання

Бізнес-правила:

· Унікально ідентифікується назвою країни

2.3.6 Сутність «Місто»

Місто - сутність-класифікатор, яка найбільш точно характеризує місце народження та місце перебування користувача

Атрибути:

· Назва

Зв'язки:

· Місто обов'язково повинно відноситись до певної країни;

· Для одного користувача може бути визначений тільки одне місто проживання і одне рідне місто.

Бізнес-правила:

· Унікально ідентифікується назвою країни в якій знаходиться та назвою міста.

2.3.7 Сутність «Структура повідомлення»

Сутруктура повідомлення - використовується для збереження повідомлень надісланих від одного користувача іншому

Атрибути:

· Текст повідомлення

· Дата та час надсилання

Зв'язки:

· Інформаційний ресурс - файл, який додається до повідомлення

Бізнес-правила:

· Всі атрибути є обов'язковими, але не унікальними

2.3.8 Сутність «Повідомлення»

Сутність повідомлення використовується для збереження повідомлень надісланих від одного користувача, який не встановлений як «недруг» іншому

Атрибути:

· Структура повідомлення

· Стан підтвердження читання

Зв'язки:

· Адресант - користувач, який надсилає повідомлення (не може співпадати з користувачем, який встановлений як «недруг» адресату)

· Адресат - користувач, який отримує повідомлення (не може співпадати з адресантом, тобто самому собі не можна слати повідомлення)

Бізнес-правила:

· Всі атрибути є обов'язковими, але не унікальними.

2.3.9 Сутність «Медіафайл»

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

Атрибути:

· URL адреса файлу

· Назва файлу

Зв'язки:

· Обов'язково повинен бути визначений один автор файлу із сутності «Користувач»

· Обов'язково для кожного файлу повинен бути визначений тип інформаційного ресурсу із переліку типів файлів сутності «Тип медіафайлу»

Бізнес-правила:

· Унікально ідентифікується назвою файлу, типом файлу та зв'язком із користувачем.

2.3.10 Сутність «Тип медіафайлу»

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

Атрибути:

· Назва типу

Зв'язки:

· Для одного файлу обов'язково повинен бути визначений один тип файлу.

Бізнес-правила:

· Унікально ідентифікується назвою типу файлу

2.3.11 Сутність «Новини»

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

Атрибути:

· Назва новини

· Текст новини

· Дата та час публікації

Зв'язки:

· Автором новини може бути тільки один із існуючих користувачів

Бізнес-правила:

· Унікально ідентифікується парою значень: користувач-автор новини та час публікації новини.

2.3.12 Сутність «Налаштування приватності»

Налаштування приватності - сутність, яка використовується для обмеження доступу до інформації користувача.

Атрибути:

· Хто може надсилати повідомлення

· Хто може переглядати інформаційні ресурси

· Хто бачить основну інформацію на сторінці

· Хто може запрошувати в додатки

· Хто може залишати повідомлення на «стіні»

· Хто може переглядати фото зі мною

· Хто може переглядати список моїх аудиозаписів

Зв'язки:

· Для одного користувача може бути визначений лише один набір налаштувань.

Бізнес-правила:

· Всі атрибути є обов'язковими, але не унікальними.

3. КОНЦЕПТУАЛЬНЕ МОДЕЛЮВАННЯ ПРЕДМЕТНОЇ ОБЛАСТІ

3.1 Теоретичні положення концептуального моделювання

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

Перший етап процесу проектування бази даних називається концептуальним проектуванням бази даних. Він полягає в створенні концептуальної моделі даних для аналізованої частини підприємства. Ця модель даних створюється на основі інформації, записаної в специфікаціях вимог користувачів. Концептуальне проектування бази даних абсолютно не залежить від таких подробиць її реалізації, як тип вибраної цільової СУБД, набір створюваних прикладних програм, використовувані мови програмування, тип вибраної обчислювальної платформи, а також від будь-яких інших особливостей фізичної реалізації. На чолі 14 представлене поетапне практичне керівництво по виконанню концептуального проектування бази даних. При розробці концептуальна модель даних постійно піддається тестуванню і перевірці на відповідність вимогам користувачів. Створена концептуальна модель даних підприємства є джерелом інформації для етапу логічного проектування бази даних.

Властивостями концептуальної моделі є наступні.

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

· Вона включає тільки концептуально релевантні аспекти ПО, крім, таким чином, БУДЬ-ЯКИХ аспектів зовнішнього або внутрішнього представлення даних. Це означає, по перше, що концептуальна модель жодним чином не повинна фіксувати конкретні потреби окремих груп користувачів або додатків. Вона повинна фіксувати, що собою представляє ПО в цілому, а не з погляду інтересів або потреб користувачів. Вона повинна інтегрувати думки, погляди й інтереси окремих користувачів, але саме інтегрувати, для одержання цілісної картини, а не виражати їхні конкретні погляди, побажання думки. По-друге, у концептуальній моделі ПО ні яким чином не повинні відбиватися які-небудь аспекти майбутньої реалізації БД у комп'ютерному середовищі. Усе, що пов'язане з такими поняттями, як способи зберігання, методи доступу, ефективність виконання, оптимізація й т.д. перебувають за межами концептуальної моделі.

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

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

· Централізоване адміністрування. Саме через концептуальну схему здійснюється адміністрування базами даних.

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

Ключовими результатами етапу концептуального моделювання э наступні:

· формальний опис інформаційного забезпечення предметної області.

· докладний і строгий опис сховищ даних.

· детальний опис потоків даних.

· детальний опис ієрархії розв'язуваних завдань із детальною специфікацією всіх завдань.

· детальний опис діючих у предметній області правил і обмежень.

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

3.2 Мова ER-моделювання ПО

Мова ER-моделювання (Entity Relationship Modeling) -- це мова визначення інформаційних потреб організації. Мова базується на концепції, відповідно до якої інформаційне забезпечення будь-якої предметної області представляється як сукупність взаємозалежних об'єктів. Процес моделювання полягає у виділенні сутностей ПО, установлення властивостей виділених сутностей і виявлення існуючих між ними зв'язків.

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

Розглянемо коротко основні властивості, формальні позначення й визначення сутностей, зв'язків, атрибутів.

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

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

· ім'я;

· ступінь/потужність;

· факультативність -- обов'язкова або факультативна.

Ці властивості використовуються для опису асоціації з кожної зі сторін, для завдання зв'язку повинні бути визначені обидва її кінця.

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

При читанні зв'язку з обов'язкової сторони перед її ім'ям використовуються слова "у всіх випадках" або "завжди"; для факультативної сторони використовуються слова "у загальному випадку" або "іноді". Ступінь "багато" читається як "один або декілька", а ступінь "один" -- "один і тільки один".

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

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

Атрибут описує одну сутність. Атрибут повинен описувати ту сутність, до якої він віднесений. У кожний момент часу сутність може володіти лише одним значенням атрибута.

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

Кожна сутність повинна однозначно ідентифікуватися за допомогою деякої комбінації атрибутів і/або зв'язків. Тому серед можливих атрибутів сутності завжди повинні бути знайдені такі атрибути, які дозволяють неї ідентифікувати. Унікальний ідентифікатор представляється на ER-Діаграмі вказівкою символу "#" перед ім'ям кожного атрибута, що входить у даний ідентифікатор. Значення усіх інших атрибутів повинні залежати від усього унікального ідентифікатора.

Дуже важливо чітко розуміти, що всі визначення сутності, зв'язку, атрибута й унікального ідентифікатора, які ми тільки що розглянули, суть визначення типу, або класу, поняття, а не екземпляра. Екземпляри сутностей і зв'язків будуть представлені в самій базі даних..

3.2 Побудова концептуальної моделі соціальної мережі

На основі проведеного аналізу предметної області була побудована концептуальна модель з використанням мови ER-моделювання. Концептуальна модель наведена на наступному рисунку. Декілька зауважень:

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

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

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

4. ЛОГІЧНЕ ТА ФІЗИЧНЕ ПРОЕКТУВАННЯ БАЗИ ДАНИХ

Завдання цього етапу полягає у проведенні логічного та фізичного проектування бази даних.

Логічне проектування бази даних. Процес створення моделі використовуваної на підприємстві інформації на основі вибраної моделі організації даних, але без урахування типу цільової СУБД і інших фізичних аспектів реалізації.

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

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

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

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

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

Фізичне проектування є третім і останнім етапом створення проекту бази даних, при виконанні якого проектувальник ухвалює рішення про способи реалізації бази даних, що розробляється. Під час попереднього етапу проектування була визначена логічна структура бази даних (яка описує відносини і обмеження в даній прикладній області). Хоча ця структура не залежить від конкретної цільової СУБД, вона створюється з урахуванням вибраної моделі зберігання даних, наприклад реляційної, мережевої або ієрархічної. Проте, приступаючи до фізичного проектування бази даних, перш за все, необхідно вибрати конкретну цільову СУБД. Тому фізичне проектування нерозривно пов'язане з конкретною СУБД. Між логічним і фізичним проектуванням існує постійний зворотний зв'язок, оскільки рішення, що приймаються на етапі фізичного проектування з метою підвищення продуктивності системи, здатні вплинути на структуру логічної моделі даних.

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

· створення набору реляційних таблиць і обмежень для них на основі інформації, представленої в глобальній логічній моделі даних;

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

· розробка засобів захисту створюваної системи.

4.1 Логічне проектування

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

Для перетворення концептуальної моделі, представленої у вигляді мови ER-моделювання, у реляційну модель, був використаний наступний алгоритм.

· Крок 1. Перетворення сутностей у таблиці. Кожна сутність перетворюється у таблицю. Ім'я сутності представляється у вигляді семантично осмисленого імені у латинському алфавіті.

· Крок 2. Перетворення атрибутів у стовпці. Кожний атрибут перетвориться в стовпець. Ім'я атрибуту представляється у вигляді семантично осмисленого імені у латинському алфавіті. У цей момент уточнюється формат представлення значень стовпця. Факультативні атрибути стають NULL-стовпцями. Обов'язкові атрибути стають NOT NULL-стовпцями.

· Крок 3. Подання унікальних ідентифікаторів ключами таблиць. Складові унікального ідентифікатора сутності стають первинним ключем таблиці. Нагадаємо, що сутність може мати більш ніж один унікальний ідентифікатор Тому вибирається той, котрий використовується найбільше часто. Всі інші унікальні ідентифікатори приймають обмеження цілісності UNIQUE NOT та NOT NULL.

Рис. Концептуальна ER-модель соціальної мережі

· Крок 4. Перетворення зв'язків багато-до-одного й один-до-одного в зовнішні ключі. Зв'язки типу багато-до-одного й один-до-одного породжують зовнішні ключі. Інакше кажучи, необхідно взяти унікальні ідентифікатори кожної сутності, розташованої в закінчення зв'язку зі ступенем один, і ввести його у відношення, розташоване з боку зв'язку "багато" як стовпці. Факультативним зв'язкам відповідають NULL-стовпці. Обов'язковим зв'язкам відповідають NOT NULL-стовпці.

· Крок 5. Введення спеціальних первинних ключів. Для більш адекватного відображення логічного проекту бази даних у фізичний, вводимо у всі таблиці один спеціальний стовпець з обмеженням цілісності первинного ключа. Всі ті стовпці, які мають властивість первинного ключа згідно з концептуальною моделлю, набувають обмеження цілісності UNIQUE та NOT NULL.

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

Таблиця 1. Відношення сутності «Користувач»

Назва таблиці	Users
Назва стовпця	Тип даних	Розмір	Призначення	Обмеження цілісності
UsersPK	Number	5	Унікальний числовий ідентифікатор користувача	Первинний ключ
Email	Varchar2	40	Адреса електронної пошти користувача	Унікальне, не може бути NULL
Password	Varchar2	32	Пароль користувача, зашифрований методом md5	Не може бути NULL
TellephoneNumbrephoneNumbr	Number	13	Номер телефону (з міжнародним кодом)	Унікальне значення
FirstName	Varchar2	24	Ім'я користувача	Не може бути NULL
LastName	Varchar2	32	Прізвище користувача	Не може бути NULL
Birth	Date	-	Дата народження	Не більше ніж 01.01.2000
Sex	Varchar2	1	Стать користувача	Приймає значення `M' або 'W'
BirthSityFK	Number	7	Місце народження	Зовнішній ключ, посилається на первинний ключ таблиці Sity, при видаленні міста встановити значення NULL
Status	Varchar2	128	Статус користувача	-
Skype	Varchar2	15	Логін Skype	Унікальне значення
Preferences	Varchar2	256	Уподобання користувача	-
AddressSityFK	Number	7	Адреса проживання користувача (з точністю до населеного пункту)	Зовнішній ключ, посилається на первинний ключ таблиці Sity, при видаленні міста встановити значення NULL
TypeFK	Number	1	Тип користувача	Зовнішній ключ, посилається на первинний ключ таблиці Userstype, не може бути NULL, при видаленні видалити всі посилання на нього CASCADE)
PhotoFK	Number	10	Фотографія із зображенням користувача	Зовнішній ключ, посилається на первинний ключ таблиці Media , при видаленні фотографії встановити значення NULL
ValidEmailEmail	Varchar2	5	Статус перевірки електронної пошти	Не може бути NULL, приймає значення `True' або `False'.
ValidEmailTellephoneNumbrephone	Varchar2	5	Статус перевірки електронної пошти	Не може бути NULL, приймає значення `True' або `False'.
PrivacySettingsFK	Number	7	Налаштування приватності	Не може бути NULL.

Таблиця 2. Відношення сутності «Тип користувача»

Назва таблиці	UsersType
Назва стовпця	Тип даних	Розмір	Призначення	Обмеження цілісності
UsersTypePK	Number	1	Унікальний ідентифікатор типу користувача	Первинний ключ
Name	Varchar2	16	Назва типу користувача	Унікальний, не може бути NULL

Таблиця 3. Відношення сутності «Відношення»

Назва таблиці	Relation
Назва стовпця	Тип даних	Розмір	Призначення	Обмеження цілісності
FromFK	Number	5	Ідентифікатор першого користувача	Зовнішній ключ, що посилається на первинний ключ таблиці Users, не може бути NULL ,при видалення користувача видалити всі посилання на нього (CASCADE)
ToFK	Number	5	Ідентифікатор другого користувача	Зовнішній ключ, що посилається на первинний ключ таблиці Users, не може бути NULL, не дорівнює Fromfk,при видалення користувача видалити всі посилання на нього (CASCADE)
RelationTypeFK	Number	1	Ідентифікатор типу відношення	Зовнішній ключ, що посилається на первинний ключ таблиці Relation, не може бути NULL, при видалення відношення видалити всі посилання на нього (CASCADE)
ValidEmail	Varchar2	5	Статус підтвердження достовірності відношення користувачами	Не може бути NULL, приймає значення `True' або `False'.
Обмеження цілісності таблиці	Пара (FromFK, ToFK) є первинним ключем

Таблиця 4. Відношення сутності «Тип відношення»

Назва таблиці	RelationType
Назва стовпця	Тип даних	Розмір	Призначення	Обмеження цілісності
RelationTypePK	Number	1	Унікальний ідентифікатор типу відношення	Первинний ключ
Name	Varchar2	16	Назва типу відношення між користувачами	Унікальний, не може бути NULL

Таблиця 5. Відношення сутності «Країна»

Назва таблиці	Country
Назва стовпця	Тип даних	Розмір	Призначення	Обмеження цілісності
CountryPK	Number	3	Унікальний ідентифікатор країни	Первинний ключ
Name	Varchar2	32	Назва країни	Унікальний, не може бути NULL

Таблиця 6. Відношення сутності «Місто»

Назва таблиці	Sity
Назва стовпця	Тип даних	Розмір	Призначення	Обмеження цілісності
SityPK	Number	7	Унікальний ідентифікатор країни	Первинний ключ
SityFK	Number	5	Країна, в якому розміщений населений пункт	Зовнішній ключ, що посилається на первинний ключ таблиці Sity, не може бути NULL, при видаленні регіону видалити всі посилання на нього (CASCADE)
Name	Varchar2	32	Назва населеного пункту	Унікальний, не може бути NULL

Таблиця 7. Відношення сутності «Структура повідомлення»

Назва таблиці	StructMessage
Назва стовпця	Тип даних	Розмір	Призначення	Обмеження цілісності
StructMessagePK	Number	5	Унікальний ідентифікатор кожного елементу повідомлення	Первинний ключ
Text	Varchar2	256	Текст повідомлення	Не може бути NULL
Date_	Date		Дата надсилання	Не може бути NULL
InfResourceFK	Number	5	Ідентифікатор інформаційного ресурсу	-

Таблиця 8. Відношення сутності «Повідомлення»

Назва таблиці	Message
Назва стовпця	Тип даних	Розмір	Призначення	Обмеження цілісності
MessagePK	Number	16	Унікальний ідентифікатор кожного повідомлення	Первинний ключ
StructMessageFK	Number	5	Ідентифікатор структури повідомлення	-
FromFK	Number	5	Ідентифікатор першого користувача	Зовнішній ключ, що посилається на первинний ключ таблиці Users, не може бути NULL, при видаленні користувача видалити всі посилання на нього (CASCADE)
ToFK	Number	5	Ідентифікатор другого користувача	Зовнішній ключ, що посилається на первинний ключ таблиці Users, не може бути NULL, не дорівнює Fromfk, при видаленні користувача видалити всі посилання на нього (CASCADE)
Read	Varchar2	5	Статус підтвердження достовірності відношення користувачами	Не може бути NULL, приймає значення `True' або `False'.

Таблиця 9. Відношення сутності «Медіафайл»

Назва таблиці	Multimedia
Назва стовпця	Тип даних	Розмір	Призначення	Обмеження цілісності
MultimediaPK	Number	12	Унікальний ідентифікатор кожного файлу	Первинний ключ
Url	Varchar2	256	Url адреса файлу	Не може бути NULL
UsersFK	Number	5	Ідентифікатор номера користувача	Зовнішній ключ, що посилається на первинний ключ таблиці Users, не може бути NULL, при видаленні користувача видалити всі посилання на нього (CASCADE)
Name	Varchar2	128	Назва файлу	не може бути NULL
MultimediaTypeFK	Number	1	Тип медіафайлу	Зовнішній ключ, що посилається на первинний ключ таблиці Mediatype, не може бути NULL, при видаленні типу видалити всі посилання на нього (CASCADE)
Обмеження цілісності таблиці	Пара (Url, Usersfk) повинна бути унікальною Пара (Url, MultimediaTypeFK) повинна бути унікальною

Таблиця 10. Відношення сутності «Тип медіафайлу»

Назва таблиці	MultimediaType
Назва стовпця	Тип даних	Розмір	Призначення	Обмеження цілісності
MultimediaTypePK	Number	1	Унікальний ідентифікатор типу медіафайлу	Первинний ключ
Name	Varchar2	12	Назва типу медіафайлу	Унікальний, не може бути NULL

Таблиця 11. Відношення сутності «Новини»

Назва таблиці	News
Назва стовпця	Тип даних	Розмір	Призначення	Обмеження цілісності
NewsPK	Number	12	Унікальний ідентифікатор новини	Первинний ключ
UsersFK	Number	5	Ідентифікатор користувача, автора новини	Зовнішній ключ, що посилається на первинний ключ таблиці Users, не може бути NULL, при видалення користувача видалити всі посилання на нього (CASCADE)
Name	Varchar2	128	Назва новини	не може бути NULL
Text	Varchar2	2048	Вміст новини	не може бути NULL
Date_	Date		Дата публікації новини	не може бути NULL
Обмеження цілісності таблиці	Пара (UsersFK, Name) повинна бути унікальною Пара (UsersFK, Text) повинна бути унікальною

Таблиця 12. Відношення сутності «Налаштування приватності»

Назва таблиці	PrivacySettings
Назва стовпця	Тип даних	Розмір	Призначення	Обмеження цілісності
PrivacySettingsPK	Number	7	Унікальний ідентифікатор	Первинний ключ
SendMessage	Varchar2	50	Хто може надсилати повідомлення	Може приймати значення `All', `Only friends', `friends of friends', `some friends', `all but'
GeneralInformation	Varchar2	50	Хто може бачити основну інформацію користувача	Може приймати значення `All', `Only friends', `friends of friends', `some friends', `all but'
WatchMultimedias	Varchar2	50	Назва файлу	Може приймати значення `All', `Only friends', `friends of friends', `some friends', `all but'
WhoCanIntiveApplications	Varchar2	50	Хто може надсилати запрошення в додатки	Може приймати значення `All', `Only friends', `friends of friends', `some friends', `all but'
WhoCanPostMassegesWall	Varchar2	50	Хто може залишати повідомлення на «стіні»	Може приймати значення `All', `Only friends', `friends of friends', `some friends', `all but'
WhoСanSeePhotosOfMe	Varchar2	50	Хто може переглядати фото зі мною	Може приймати значення `All', `Only friends', `friends of friends', `some friends', `all but'
WhoСanSeeMyAudio	Varchar2	50	Хто може переглядати список моїх аудиозаписів	Може приймати значення `All', `Only friends', `friends of friends', `some friends', `all but'

4.2 Фізичне проектування

База даних спроектована для її збереження у СКБД Oracle, яка підтримує реляційну модель даних і є об'єкто-реляційною СКБД. Ця СКБД має дуже розвинені можливості по створенню та супроводу баз даних, оскільки володіє найбільш розвиненою системою типів даних, можливостями індексування полів, що дозволяє одержувати доступ до даних за мінімальний час, а також функціями по забезпеченню підтримки цілісності даних між реляційними таблицями, що дозволяє розробнику мінімізувати тимчасові витрати на створення бази даних, а кінцевому користувачеві витрати на підтримку цілісності збережених даних і одержання даних з бази даних. Робота з базою даних підтримується за допомогою реляційної мови запитів SQL.

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

4.2.1 Скрипти створення бази даних

Наведемо скрипт мови SQL Oracle, який створює таблиці БД:

CREATE TABLE Users

(UsersPK NUMBER(5) CONSTRAINT Users_UsersPK_constr_1 PRIMARY KEY,

Email VARCHAR2(40) NOT NULL CONSTRAINT Users_Email_constr_1 UNIQUE,

Password VARCHAR2(32) NOT NULL,

FirstName VARCHAR2(32) NOT NULL ,

LastName VARCHAR2(40) NOT NULL,

Birth DATE CONSTRAINT Users_Birth_constr_1 CHECK(Birth < to_date('01.01.2005', 'dd.mm.yyyy')),

Sex VARCHAR2(1) CONSTRAINT Users_Sex_constr_1 CHECK(Sex IN('M', 'F')),

BirthSityFK NUMBER(7) CONSTRAINT Users_BirthSityFK_constr_1 REFERENCES Sity(SityPK) ON DELETE SET NULL,

Status VARCHAR2(128),

TellephoneNumbr NUMBER(13) CONSTRAINT Users_TellephoneNumbr_constr_1 UNIQUE,

Skype VARCHAR2(15) CONSTRAINT Users_Skype_constr_1 UNIQUE,

Preferences VARCHAR2(256),

AddressSityFK NUMBER(7) CONSTRAINT Users_AddressSityFK_constr_1 REFERENCES Sity(SityPK) ON DELETE SET NULL,

TypeFK NUMBER(1) CONSTRAINT Users_TypeFK_constr_1 REFERENCES UsersType(UsersTypePK) ON DELETE SET NULL,

PhotoFK NUMBER(1),

ValidEmail VARCHAR(5) NOT NULL CONS...