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

Автор работы: Пользователь скрыл имя, 18 Ноября 2013 в 20:21, курсовая работа

Описание работы

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

Содержание работы

ЗМІСТ
ВСТУП 3
1. СТРАТЕГІЯ АВТОМАТИЗАЦІЇ ПРЕДМЕТНОЇ ОБЛАСТІ 3
1.1. Загальні положення 3
1.2. Мета, цілі та задачі створення бази даних 4
1.3. Вимоги до інформаційного забезпечення 4
2. АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ 5
2.1. Загальні положення системного аналізу ПО 5
2.2. Загальні положення соціальної мережі 5
2.3. Системний аналіз предметної області 6
3. КОНЦЕПТУАЛЬНЕ МОДЕЛЮВАННЯ ПРЕДМЕТНОЇ ОБЛАСТІ 10
3.1. Теоретичні положення концептуального моделювання 10
3.2. Мова ER—моделювання ПО 12
3.2. Побудова концептуальної моделі соціальної мережі 13
4. ЛОГІЧНЕ ТА ФІЗИЧНЕ ПРОЕКТУВАННЯ БАЗИ ДАНИХ 13
4.1. Логічне проектування 14
Таблиця 1. Відношення сутності «Користувач» 15
Таблиця 2. Відношення сутності «Тип користувача» 17
Таблиця 3. Відношення сутності «Відношення» 17
Таблиця 4. Відношення сутності «Тип відношення» 18
Таблиця 5. Відношення сутності «Країна» 18
Таблиця 6. Відношення сутності «Місто» 18
Таблиця 7. Відношення сутності «Структура повідомлення» 19
Таблиця 8. Відношення сутності «Повідомлення» 19
Таблиця 9. Відношення сутності «Медіафайл» 20
Таблиця 10. Відношення сутності «Тип медіафайлу» 20
Таблиця 11. Відношення сутності «Новини» 21
Таблиця 12. Відношення сутності «Налаштування приватності» 21
4.2. Фізичне проектування 22
4.2.1. Скрипти створення бази даних 22
4.2.2 SQL- скрипт заповнення початковими даними 25
4.2.3. Інформаційно–пошукові запити 26
ВИСНОВКИ 28

Файлы: 1 файл

Курсач.docx

— 99.70 Кб (Скачать файл)

 

Таблиця 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 CONSTRAINT Users_ValidEmailEmail_constr_1 CHECK (ValidEmail IN('True', 'False')));

ValidTelephone VARCHAR(5)  NOT NULL CONSTRAINT Users_ValidEmailEmail_constr_1 CHECK (ValidEmail IN('True', 'False')));

 

CREATE TABLE UsersType

(

UsersTypePK NUMBER(1) CONSTRAINT UsersTypePK_constr_1 PRIMARY KEY,

Name VARCHAR2(16) NOT NULL CONSTRAINT UsersType_Name_constr_1 UNIQUE

);

 

CREATE TABLE Relation

(

FromFK NUMBER(5) NOT NULL CONSTRAINT Relation_FromFK_constr_1 REFERENCES Users(UsersPK) ON DELETE CASCADE,

ToFK NUMBER(5) NOT NULL CONSTRAINT Relation_ToFK_constr_1 REFERENCES Users(UsersPK) ON DELETE CASCADE,

RelationTypeFK NUMBER(1) NOT NULL CONSTRAINT Relation_RelTypeFK_constr_1 REFERENCES RelationType(RelationTypePK) ON DELETE CASCADE,

ValidEmail VARCHAR(1)  NOT NULL CONSTRAINT Relation_ValidEmail_constr_1 CHECK (ValidEmail IN('T', 'F')),

CONSTRAINT Relationpk_constr_1 PRIMARY KEY (FromFK, ToFK)

);

 

CREATE TABLE RelationType

(

RelationTypePK NUMBER(1) CONSTRAINT Relationtypepk_constr_1 PRIMARY KEY,

Name VARCHAR2(16) NOT NULL CONSTRAINT Relationtype_Name_constr_1 UNIQUE

);

 

CREATE TABLE Country

(

CountryPK NUMBER(3) CONSTRAINT CountryPK_constr_1 PRIMARY KEY,

Name VARCHAR2(64) NOT NULL CONSTRAINT Country_Name_constr_1 UNIQUE

);

 

 

CREATE TABLE Sity

(

SityPK NUMBER(7) CONSTRAINT Sity_constr_1 PRIMARY KEY,

SityFK NUMBER(5) NOT NULL CONSTRAINT Sity_SityFK_constr_1 REFERENCES Sity(SityPK) ON DELETE CASCADE,

Name VARCHAR2(32) NOT NULL CONSTRAINT Sity_Name_constr_1 UNIQUE

);

 

CREATE TABLE StructMessage

(

StructMessagePK Number(5) CONSTRAINT StructMessagePK_constr_1 PRIMARY KEY,

Text VARCHAR2(256) NOT NULL,

Date_ DATE NOT NULL,

InfResourceFK Number(5) CONSTRAINT InfResourceFK_constr_1 REFERENCES Multimedia(MultimediaPK) ON DELETE CASCADE

);

 

CREATE TABLE Message

(

MessagePK NUMBER(16) CONSTRAINT MessagePK_constr_1 PRIMARY KEY,

StructMessageFK Number(5) CONSTRAINT StructMessageFK_constr_1 REFERENCES StructMessage(StructMessagePK) ON DELETE CASCADE,

FromFK NUMBER(5) NOT NULL CONSTRAINT Message_FromFK_constr_1 REFERENCES Users(UsersPK) ON DELETE CASCADE,

ToFK NUMBER(5) NOT NULL CONSTRAINT Message_ToFK_constr_1 REFERENCES Users(UsersPK) ON DELETE CASCADE,

Read VARCHAR(5)  NOT NULL CONSTRAINT Message_Read_constr_1 CHECK (Read IN('True', 'False'))

);

 

ALTER TABLE Users add CONSTRAINT Users_Photofk_constr_1 FOREIGN KEY (Photofk) REFERENCES Multimedia(MultimediaPK) ON DELETE SET NULL;

 

CREATE TABLE Multimedia

(

MultimediaPK NUMBER(12) CONSTRAINT IRPK_constr_1 PRIMARY KEY,

Url VARCHAR2(256) NOT NULL,

UsersFK NUMBER(5) NOT NULL CONSTRAINT Media_UsersFK_constr_1 REFERENCES Users(UsersPK) ON DELETE CASCADE,

Name VARCHAR2(128) NOT NULL,

MultimediaTypeFK NUMBER(1) NOT NULL CONSTRAINT Media_Mediatype_constr_1 REFERENCES MultimediaType(MultimediaTypePK) ON DELETE CASCADE,

CONSTRAINT Media_constr_1 UNIQUE (Url, UsersFK),

CONSTRAINT Media_constr_2 UNIQUE (Url, MultimediaTypeFK)

);

CREATE TABLE MultimediaType

(

MultimediaPK NUMBER(1) CONSTRAINT IRTypePK_constr_1 PRIMARY KEY,

Name VARCHAR2(12) NOT NULL CONSTRAINT IRType_Name_constr_1 UNIQUE

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