Summarize this content to 400 words in Persian Lang
اعتبار تصویر: مارتین کلپمن، *طراحی برنامه های کاربردی داده فشرده*، رسانه O’Reilly، 2017.
انواع مدل های داده
سلسله مراتبی (مدل اولیه) ← به خوبی با روابط سازگار نشد چند به چند
رابطه ای (SQL) → راه حل مدل سلسله مراتبی. خیلی انعطاف پذیر نیست
مستند ← داده‌هایی که در اسناد خودکفایی (JSON) ارائه می‌شوند. پشتیبانی ارتباط کمی بین اسناد
مدل نمودار ← گره ها و محورها
مدل رابطه ای
پیشنهاد شده توسط ادگار کاد در سال 1970
داده ها در روابط (جدول) سازماندهی می شوند که در آن هر رابطه مجموعه ای نامرتب از تاپل ها (ردیف ها) است.
موارد استفاده اصلی
پردازش تراکنش ← عملیات جابجایی پول در بانک، رزرو خطوط هوایی
پردازش تحلیلی در دسته → گزارش ها، حقوق و دستمزد، تجزیه و تحلیل
از پارادایم پیروی کنید طرحواره روی نوشتن (رئوس مطالب هنگام نوشتن)
طرح داده صریح است و موتور DB تضمین می کند که تمام داده های نوشته شده در DB با طرح از پیش تعریف شده سازگار است.
NoSQL
این با هشته توییتر در سال 2009 ظاهر شد
دف. نه تنها SQL
از پارادایم پیروی کنید طرحواره در خواندن (طرح کلی هنگام خواندن)
به دلیل این عوامل ایجاد شد:
نیاز به مقیاس پذیری بیشتر از پایگاه داده های رابطه ای
ترجیح نرم افزار منبع باز رایگان نسبت به محصولات پایگاه داده رابطه ای سازمانی
عملیات پرس و جو تخصصی که توسط مدل رابطه ای به خوبی پشتیبانی نمی شوند
ناامیدی از محدودیت های طرح های رابطه ای
نیاز به مدلی پویاتر و گویاتر
مشکل: اشیاء در مقابل روابط → عدم تطابق امپدانس
عدم تطابق امپدانس: مشکل ناسازگاری بین مدل رابطه ای و اشیاء در کد برنامه. مجموعه ای از مشکلات فنی و مفهومی است که هنگام ذخیره سازی ایجاد می شود اشیاء برنامه نویسی در پایگاه های داده با مدل های رابطه ای
اگر اشیاء در برنامه در یک پایگاه داده با یک مدل رابطه ای (SQL) ذخیره شوند، یک لایه ترجمه بین کد برنامه و مدل پایگاه داده لازم است.
راه حل → نگاشت شی – رابطه ای (ORM: نگاشت شی رابطه ای)
چارچوب های ORM
کد را کم می کنند دیگ بخار برای آن لایه انتقال مورد نیاز است
مثال‌ها: Apache OpenJPA، SQLAlchemy، TypeORM
عبارات در مدل های مختلف
پروفایل لینکدین
مدل رابطه ای
مارتین کلپمن، طراحی برنامه های کاربردی داده فشرده، رسانه O’Reilly، 2017.
– Modelo Documental NoSQL (JSON)
“`json
{
“user_id”: 251,
“first_name”: “pedro”,
“positions”: [
{“job_title”: “founder”, “organization”: “planny”},
{“job_title”: “ceo”, “organization”: “nombre undefined”}
],
…
}
“`
– Con el modelo JSON, la estructura de árbol implicita en el perfil de Linkedin, se vuelve explicita en el modelo de datos
نسخه‌های اولیه یک برنامه کاربردی ممکن است به خوبی با مدل سند بدون JOIN مطابقت داشته باشد. اما داده ها تمایل دارند که با ظهور عملکرد جدید بیشتر به هم مرتبط شوند
در یک نقطه شما نیاز خواهید داشت چند به چند و بنابراین استفاده کنید می پیوندد
مثال لینکدین ← سازمانی را که در آن شخص به عنوان یک موجودیت کار می کند را نشان دهید.
مناظره: ¿چگونه روابط موجودیت را در یک پایگاه داده به بهترین شکل نشان دهیم؟
بحث قدیمی تر از طرح های NoSQL. از اولین سیستم های پایگاه داده کامپیوتری می آید
مورد: IMS IBM از مدل سلسله مراتبی استفاده کرد. این مدل از JOIN پشتیبانی نمی کرد. در دهه 1960، توسعه دهندگان باید تصمیم می گرفتند که آیا داده ها را کپی کنند (Normalize) یا به صورت دستی مراجع را از یک رکورد به رکورد دیگر حل کنند. این همان مشکلی است که امروزه توسعه دهندگان با پایگاه داده های مستند دارند.
راه حل این موضوع در آن زمان مدل رابطه ای بود SQL
مدل رابطه‌ای اجازه می‌دهد تا همه داده‌ها با فهرستی از تاپل‌ها (جدول) آشکار شوند. بهینه ساز پرس و جو در یک پایگاه داده رابطه ای به طور خودکار تصمیم می گیرد که چه بخش هایی از پرس و جو را اجرا کند و به چه ترتیبی این کار را انجام دهد. این تصمیمات دیگر توسط یک توسعه دهنده گرفته نمی شود
«شما فقط یک بار یک بهینه ساز پرس و جو می سازید. همه برنامه هایی که از DB استفاده می کنند از آن بهره مند می شوند.
پایگاه‌های داده سند به مدل سلسله مراتبی بازگشتند ← رکوردهای تعبیه‌شده (چند به یک) را در یک رکورد، نه در جدول دیگر ذخیره می‌کند.
وقتی صحبت از روابط چند به چند می شود، مدل اسنادی و مدل رابطه ای تفاوت چندانی با هم ندارند. در هر دو، آیتم مرتبط با یک شناسه منحصربه‌فرد ارجاع می‌شود که به عنوان کلید خارجی در مورد دیگر در مدل رابطه‌ای استفاده می‌شود، اما به عنوان ارجاع به یک سند در مدل اسنادی استفاده می‌شود.
مدل رابطه ای در مقابل مدل مستند
مستند
انعطاف پذیری طرحواره
موقعیت بهتر داده ← امکان انتقال محاسبات (اشیاء) به داده های ذخیره شده
عملکرد بهتر
پشتیبانی کوچک JOINS
رابطه ای
پشتیبانی پیوستن خوب
پشتیبانی خوب از روابط چند به یک و چند به چند
انعطاف پذیری کمی در طرح
همگرایی بین مدل رابطه ای و اسنادی؟
Postgres قبلاً از اسناد JSON به عنوان یک نوع داده از نسخه 9 پشتیبانی می کند
درایورهای Mongo وجود دارند که به طور خودکار مراجع سند را حل می کنند
مشکل را از سمت مشتری حل کنید
به نظر می رسد که BD های رابطه ای و مستند هر روز بیشتر شبیه هم می شوند. این چیز خوبی است زیرا مدل های داده مکمل یکدیگر هستند. اگر یک DB پشتیبانی می کند مانند سند، و همچنین از پرس‌و‌جوهای رابطه‌ای پشتیبانی می‌کند، برنامه‌ها می‌توانند از ترکیبی از هر دو عملکرد استفاده کنند که به بهترین وجه با نیازهای آنها مطابقت دارد.
در حال حاضر
وقتی از مستند استفاده کنید
شما داده هایی با روابط یک به چند دارید
نیاز به یک درخت داده جاسازی شده برای بارگذاری در برنامه از زمان راه اندازی دارد
ساختار داده نوع سند
وقتی از روابط رابطه ای استفاده کنید
به پشتیبانی پیوستن بسیار خوبی نیاز دارد
روابط چند به چند دارد
زبان های پرس و جو
دو نوع زبان: اعلانی و امری
اعلانی → SQL
به دستگاه می گویم چی داده ها و تبدیل ها می خواهم در برابر داده ها انجام دهم، اما من به شما نمی گویم چگونه پرس و جو را انجام دهید
SELECT * FROM animals WHERE family = “sharks”
Imperative → زبان های برنامه نویسی (جاوا، پایتون، JS)
به دستگاه می گویم، به عنوان پرس و جو را اجرا کنید
function getSharks(){
var sharks = [];
for (var i=0; i<animals.length; i++){
if(animals[i].family === “sharks”){
sharks.push(animals[i]);
}
}
return sharks;
}
همین پرس و جو را می توان به طور کلی با جبر رابطه ای بیان کرد
SQL برای برخی از انواع پرس و جوها پشتیبانی بهتری ارائه می دهد
نقشه کاهش پرس و جوهای نوع (اسناد) → Je: تعداد کوسه ها را در ماه بدست آورید
SQL
SELECT date_trunc(‘month’, observation_timestamp) AS observation_month, 1
sum(num_animals) AS total_animals
FROM observations
WHERE family = ‘Sharks’
GROUP BY observation_month;
مستند (مونگو)
db.observations.mapReduce(
function map() { 2
var year = this.observationTimestamp.getFullYear();
var month = this.observationTimestamp.getMonth() + 1;
emit(year + “-” + month, this.numAnimals); 3
},
function reduce(key, values) { 4
return Array.sum(values); 5
},
{
query: { family: “Sharks” }, 1
out: “monthlySharkReport” 6
}
);
مدل نمودار
پایگاه داده ای که داده ها را به عنوان روابط بین گره های متصل به لبه ها ذخیره می کند
مثال: نشان دهنده ازدواج دو نفر است
ساختار → Neo4J مثال
هر رأس (گره) شامل
شناسه
محورها به بیرون
محورها به سمت داخل
ویژگی های کلید-مقدار
هر محور شامل
شناسه
راس مبدا
سران سرنوشت
برچسب
ویژگی های کلید-مقدار
نمودارها برای تکامل سیستم بسیار خوب هستند. یک نمودار را می توان به راحتی گسترش داد تا تغییرات ساختار داده برنامه را در خود جای دهد.
مثالی از زبان برای پایگاه داده های گراف → Cypher (زبان پرس و جو مورد استفاده در Neo4J)
مثال: این واقعیت را درج کنید که آیداهو در ایالات متحده آمریکا است و ایالات متحده آمریکا در آمریکای شمالی است. درج کنید که لوسی در آیداهو به دنیا آمد
CREATE
(NAmerica:Location {name: ‘north america’, type: ‘continent’}),
(USA:Location {name:’united staes’, type: ‘country’}),
(Idaho:Location {name: ‘idaho’, type ‘state’}),
(Lucy: Person {name:’Lucy’}),
(Idaho) -[:WITHIN] -> (USA) -[:WITHIN] -> (NAmerica)
(Lucy) -[:BORN_IN] -> (Idaho)
این مدل به شما امکان می دهد از پرس و جوهای بسیار پیچیده پشتیبانی کنید
مثال: اسامی افرادی که از ایالات متحده آمریکا به اروپا مهاجرت کرده اند را بیابید
MATCH
(person) -[:BORN_IN]-> () -[:WITHIN*0..]-> (us:Location {name:’United States’}),
(person) -[:LIVES_IN]-> () -[:WITHIN*0..]-> (eu:Location {name:’Europe’})
RETURN person.name
//[:WITHIN*0..] -> follow a within edge, zero or more times
تمام رئوس (افراد) که
یک متولد_در محور به یک راس از آن راس یک محور زنجیره ای را دنبال کنید در داخل تا زمانی که به مکانی که ایالات متحده آمریکا است برسید
همان راس (شخص) دارای یک محور است زندگی می کند که به رئوسی منتهی می شود که متعلق به اروپاست
اگر بخواهم همان پرس و جو را در SQL انجام دهم، چیزی شبیه به این خواهد بود
— in_usa is the set of vertex IDs of all locations within the United States
in_usa(vertex_id) AS (
SELECT vertex_id FROM vertices WHERE properties->>’name’ = ‘United States’ 1
UNION
SELECT edges.tail_vertex FROM edges 2
JOIN in_usa ON edges.head_vertex = in_usa.vertex_id
WHERE edges.label = ‘within’
),
— in_europe is the set of vertex IDs of all locations within Europe
in_europe(vertex_id) AS (
SELECT vertex_id FROM vertices WHERE properties->>’name’ = ‘Europe’ 3
UNION
SELECT edges.tail_vertex FROM edges
JOIN in_europe ON edges.head_vertex = in_europe.vertex_id
WHERE edges.label = ‘within’
),
— born_in_usa is the set of vertex IDs of all people born in the US
born_in_usa(vertex_id) AS ( 4
SELECT edges.tail_vertex FROM edges
JOIN in_usa ON edges.head_vertex = in_usa.vertex_id
WHERE edges.label = ‘born_in’
),
— lives_in_europe is the set of vertex IDs of all people living in Europe
lives_in_europe(vertex_id) AS ( 5
SELECT edges.tail_vertex FROM edges
JOIN in_europe ON edges.head_vertex = in_europe.vertex_id
WHERE edges.label = ‘lives_in’
)
SELECT vertices.properties->>’name’
FROM vertices
— join to find those people who were both born in the US *and* live in Europe
JOIN born_in_usa ON vertices.vertex_id = born_in_usa.vertex_id 6
JOIN lives_in_europe ON vertices.vertex_id = lives_in_europe.vertex_id;
فروشگاه سه گانه و SPARQL → تمام اطلاعات را در قالب عبارات سه بخشی ذخیره کنید
موضوع
محمول
شیء
مثال: جان گوستان موز
مدل “لوسی در لندن زندگی می کند”.
_:lucy a :Person.
_:lucy :name “Lucy”.
_:lucy :bornIn _:idaho.
_:idaho a :Location.
_:idaho :name “Idaho”.
_:idaho :type “state”.
_:idaho :within _:usa.
_:usa a :Location.
_:usa :name “United States”.
_:usa :type “country”.
_:usa :within _:namerica.
_:namerica a :Location.
_:namerica :name “North America”.
_:namerica :type “continent”.
توجه → Web3 (وب معنایی) بر اساس آن مدل است
اعتبار تصویر: مارتین کلپمن، *طراحی برنامه های کاربردی داده فشرده*، رسانه O’Reilly، 2017.
انواع مدل های داده
- سلسله مراتبی (مدل اولیه) ← به خوبی با روابط سازگار نشد چند به چند
- رابطه ای (SQL) → راه حل مدل سلسله مراتبی. خیلی انعطاف پذیر نیست
- مستند ← داده‌هایی که در اسناد خودکفایی (JSON) ارائه می‌شوند. پشتیبانی ارتباط کمی بین اسناد
- مدل نمودار ← گره ها و محورها
مدل رابطه ای
- پیشنهاد شده توسط ادگار کاد در سال 1970
- داده ها در روابط (جدول) سازماندهی می شوند که در آن هر رابطه مجموعه ای نامرتب از تاپل ها (ردیف ها) است.
- موارد استفاده اصلی
- پردازش تراکنش ← عملیات جابجایی پول در بانک، رزرو خطوط هوایی
- پردازش تحلیلی در دسته → گزارش ها، حقوق و دستمزد، تجزیه و تحلیل
- از پارادایم پیروی کنید طرحواره روی نوشتن (رئوس مطالب هنگام نوشتن)
- طرح داده صریح است و موتور DB تضمین می کند که تمام داده های نوشته شده در DB با طرح از پیش تعریف شده سازگار است.
NoSQL
- این با هشته توییتر در سال 2009 ظاهر شد
- دف. نه تنها SQL
- از پارادایم پیروی کنید طرحواره در خواندن (طرح کلی هنگام خواندن)
- به دلیل این عوامل ایجاد شد:
- نیاز به مقیاس پذیری بیشتر از پایگاه داده های رابطه ای
- ترجیح نرم افزار منبع باز رایگان نسبت به محصولات پایگاه داده رابطه ای سازمانی
- عملیات پرس و جو تخصصی که توسط مدل رابطه ای به خوبی پشتیبانی نمی شوند
- ناامیدی از محدودیت های طرح های رابطه ای
- نیاز به مدلی پویاتر و گویاتر
مشکل: اشیاء در مقابل روابط → عدم تطابق امپدانس
-
عدم تطابق امپدانس: مشکل ناسازگاری بین مدل رابطه ای و اشیاء در کد برنامه. مجموعه ای از مشکلات فنی و مفهومی است که هنگام ذخیره سازی ایجاد می شود اشیاء برنامه نویسی در پایگاه های داده با مدل های رابطه ای
- اگر اشیاء در برنامه در یک پایگاه داده با یک مدل رابطه ای (SQL) ذخیره شوند، یک لایه ترجمه بین کد برنامه و مدل پایگاه داده لازم است.
-
راه حل → نگاشت شی – رابطه ای (ORM: نگاشت شی رابطه ای)
- چارچوب های ORM
- کد را کم می کنند دیگ بخار برای آن لایه انتقال مورد نیاز است
- مثال‌ها: Apache OpenJPA، SQLAlchemy، TypeORM
عبارات در مدل های مختلف
- پروفایل لینکدین
- مدل رابطه ای
مارتین کلپمن، طراحی برنامه های کاربردی داده فشرده، رسانه O’Reilly، 2017.
- Modelo Documental NoSQL (JSON)
```json
{
"user_id": 251,
"first_name": "pedro",
"positions": [
{"job_title": "founder", "organization": "planny"},
{"job_title": "ceo", "organization": "nombre undefined"}
],
...
}
```
- Con el modelo JSON, la estructura de árbol implicita en el perfil de Linkedin, se vuelve explicita en el modelo de datos
نسخه‌های اولیه یک برنامه کاربردی ممکن است به خوبی با مدل سند بدون JOIN مطابقت داشته باشد. اما داده ها تمایل دارند که با ظهور عملکرد جدید بیشتر به هم مرتبط شوند
- در یک نقطه شما نیاز خواهید داشت چند به چند و بنابراین استفاده کنید می پیوندد
-
مثال لینکدین ← سازمانی را که در آن شخص به عنوان یک موجودیت کار می کند را نشان دهید.
مناظره: ¿چگونه روابط موجودیت را در یک پایگاه داده به بهترین شکل نشان دهیم؟
- بحث قدیمی تر از طرح های NoSQL. از اولین سیستم های پایگاه داده کامپیوتری می آید
- مورد: IMS IBM از مدل سلسله مراتبی استفاده کرد. این مدل از JOIN پشتیبانی نمی کرد. در دهه 1960، توسعه دهندگان باید تصمیم می گرفتند که آیا داده ها را کپی کنند (Normalize) یا به صورت دستی مراجع را از یک رکورد به رکورد دیگر حل کنند. این همان مشکلی است که امروزه توسعه دهندگان با پایگاه داده های مستند دارند.
- راه حل این موضوع در آن زمان مدل رابطه ای بود SQL
- مدل رابطه‌ای اجازه می‌دهد تا همه داده‌ها با فهرستی از تاپل‌ها (جدول) آشکار شوند. بهینه ساز پرس و جو در یک پایگاه داده رابطه ای به طور خودکار تصمیم می گیرد که چه بخش هایی از پرس و جو را اجرا کند و به چه ترتیبی این کار را انجام دهد. این تصمیمات دیگر توسط یک توسعه دهنده گرفته نمی شود
- «شما فقط یک بار یک بهینه ساز پرس و جو می سازید. همه برنامه هایی که از DB استفاده می کنند از آن بهره مند می شوند.
- پایگاه‌های داده سند به مدل سلسله مراتبی بازگشتند ← رکوردهای تعبیه‌شده (چند به یک) را در یک رکورد، نه در جدول دیگر ذخیره می‌کند.
- مدل رابطه‌ای اجازه می‌دهد تا همه داده‌ها با فهرستی از تاپل‌ها (جدول) آشکار شوند. بهینه ساز پرس و جو در یک پایگاه داده رابطه ای به طور خودکار تصمیم می گیرد که چه بخش هایی از پرس و جو را اجرا کند و به چه ترتیبی این کار را انجام دهد. این تصمیمات دیگر توسط یک توسعه دهنده گرفته نمی شود
-
وقتی صحبت از روابط چند به چند می شود، مدل اسنادی و مدل رابطه ای تفاوت چندانی با هم ندارند. در هر دو، آیتم مرتبط با یک شناسه منحصربه‌فرد ارجاع می‌شود که به عنوان کلید خارجی در مورد دیگر در مدل رابطه‌ای استفاده می‌شود، اما به عنوان ارجاع به یک سند در مدل اسنادی استفاده می‌شود.
مدل رابطه ای در مقابل مدل مستند
- مستند
- انعطاف پذیری طرحواره
- موقعیت بهتر داده ← امکان انتقال محاسبات (اشیاء) به داده های ذخیره شده
- عملکرد بهتر
- پشتیبانی کوچک JOINS
- رابطه ای
- پشتیبانی پیوستن خوب
- پشتیبانی خوب از روابط چند به یک و چند به چند
- انعطاف پذیری کمی در طرح
-
همگرایی بین مدل رابطه ای و اسنادی؟
- Postgres قبلاً از اسناد JSON به عنوان یک نوع داده از نسخه 9 پشتیبانی می کند
- درایورهای Mongo وجود دارند که به طور خودکار مراجع سند را حل می کنند
- مشکل را از سمت مشتری حل کنید
- به نظر می رسد که BD های رابطه ای و مستند هر روز بیشتر شبیه هم می شوند. این چیز خوبی است زیرا مدل های داده مکمل یکدیگر هستند. اگر یک DB پشتیبانی می کند مانند سند، و همچنین از پرس‌و‌جوهای رابطه‌ای پشتیبانی می‌کند، برنامه‌ها می‌توانند از ترکیبی از هر دو عملکرد استفاده کنند که به بهترین وجه با نیازهای آنها مطابقت دارد.
- در حال حاضر
- وقتی از مستند استفاده کنید
- شما داده هایی با روابط یک به چند دارید
- نیاز به یک درخت داده جاسازی شده برای بارگذاری در برنامه از زمان راه اندازی دارد
- ساختار داده نوع سند
- وقتی از روابط رابطه ای استفاده کنید
- به پشتیبانی پیوستن بسیار خوبی نیاز دارد
- روابط چند به چند دارد
- وقتی از مستند استفاده کنید
زبان های پرس و جو
-
دو نوع زبان: اعلانی و امری
-
اعلانی → SQL
-
به دستگاه می گویم چی داده ها و تبدیل ها می خواهم در برابر داده ها انجام دهم، اما من به شما نمی گویم چگونه پرس و جو را انجام دهید
SELECT * FROM animals WHERE family = "sharks"
-
-
Imperative → زبان های برنامه نویسی (جاوا، پایتون، JS)
-
به دستگاه می گویم، به عنوان پرس و جو را اجرا کنید
function getSharks(){ var sharks = []; for (var i=0; i<animals.length; i++){ if(animals[i].family === "sharks"){ sharks.push(animals[i]); } } return sharks; }
-
-
همین پرس و جو را می توان به طور کلی با جبر رابطه ای بیان کرد
SQL برای برخی از انواع پرس و جوها پشتیبانی بهتری ارائه می دهد
-
نقشه کاهش پرس و جوهای نوع (اسناد) → Je: تعداد کوسه ها را در ماه بدست آورید
-
SQL
SELECT date_trunc('month', observation_timestamp) AS observation_month, 1 sum(num_animals) AS total_animals FROM observations WHERE family = 'Sharks' GROUP BY observation_month; -
مستند (مونگو)
db.observations.mapReduce( function map() { 2 var year = this.observationTimestamp.getFullYear(); var month = this.observationTimestamp.getMonth() + 1; emit(year + "-" + month, this.numAnimals); 3 }, function reduce(key, values) { 4 return Array.sum(values); 5 }, { query: { family: "Sharks" }, 1 out: "monthlySharkReport" 6 } );
-
مدل نمودار
-
پایگاه داده ای که داده ها را به عنوان روابط بین گره های متصل به لبه ها ذخیره می کند
-
مثال: نشان دهنده ازدواج دو نفر است
-
ساختار → Neo4J مثال
- هر رأس (گره) شامل
- شناسه
- محورها به بیرون
- محورها به سمت داخل
- ویژگی های کلید-مقدار
- هر محور شامل
- شناسه
- راس مبدا
- سران سرنوشت
- برچسب
- ویژگی های کلید-مقدار
- هر رأس (گره) شامل
-
نمودارها برای تکامل سیستم بسیار خوب هستند. یک نمودار را می توان به راحتی گسترش داد تا تغییرات ساختار داده برنامه را در خود جای دهد.
-
مثالی از زبان برای پایگاه داده های گراف → Cypher (زبان پرس و جو مورد استفاده در Neo4J)
- مثال: این واقعیت را درج کنید که آیداهو در ایالات متحده آمریکا است و ایالات متحده آمریکا در آمریکای شمالی است. درج کنید که لوسی در آیداهو به دنیا آمد
CREATE (NAmerica:Location {name: 'north america', type: 'continent'}), (USA:Location {name:'united staes', type: 'country'}), (Idaho:Location {name: 'idaho', type 'state'}), (Lucy: Person {name:'Lucy'}), (Idaho) -[:WITHIN] -> (USA) -[:WITHIN] -> (NAmerica) (Lucy) -[:BORN_IN] -> (Idaho)-
این مدل به شما امکان می دهد از پرس و جوهای بسیار پیچیده پشتیبانی کنید
- مثال: اسامی افرادی که از ایالات متحده آمریکا به اروپا مهاجرت کرده اند را بیابید
MATCH (person) -[:BORN_IN]-> () -[:WITHIN*0..]-> (us:Location {name:'United States'}), (person) -[:LIVES_IN]-> () -[:WITHIN*0..]-> (eu:Location {name:'Europe'}) RETURN person.name //[:WITHIN*0..] -> follow a within edge, zero or more times- تمام رئوس (افراد) که
- یک متولد_در محور به یک راس از آن راس یک محور زنجیره ای را دنبال کنید در داخل تا زمانی که به مکانی که ایالات متحده آمریکا است برسید
- همان راس (شخص) دارای یک محور است زندگی می کند که به رئوسی منتهی می شود که متعلق به اروپاست
-
اگر بخواهم همان پرس و جو را در SQL انجام دهم، چیزی شبیه به این خواهد بود
-- in_usa is the set of vertex IDs of all locations within the United States in_usa(vertex_id) AS ( SELECT vertex_id FROM vertices WHERE properties->>'name' = 'United States' 1 UNION SELECT edges.tail_vertex FROM edges 2 JOIN in_usa ON edges.head_vertex = in_usa.vertex_id WHERE edges.label = 'within' ), -- in_europe is the set of vertex IDs of all locations within Europe in_europe(vertex_id) AS ( SELECT vertex_id FROM vertices WHERE properties->>'name' = 'Europe' 3 UNION SELECT edges.tail_vertex FROM edges JOIN in_europe ON edges.head_vertex = in_europe.vertex_id WHERE edges.label = 'within' ), -- born_in_usa is the set of vertex IDs of all people born in the US born_in_usa(vertex_id) AS ( 4 SELECT edges.tail_vertex FROM edges JOIN in_usa ON edges.head_vertex = in_usa.vertex_id WHERE edges.label = 'born_in' ), -- lives_in_europe is the set of vertex IDs of all people living in Europe lives_in_europe(vertex_id) AS ( 5 SELECT edges.tail_vertex FROM edges JOIN in_europe ON edges.head_vertex = in_europe.vertex_id WHERE edges.label = 'lives_in' ) SELECT vertices.properties->>'name' FROM vertices -- join to find those people who were both born in the US *and* live in Europe JOIN born_in_usa ON vertices.vertex_id = born_in_usa.vertex_id 6 JOIN lives_in_europe ON vertices.vertex_id = lives_in_europe.vertex_id;
-
فروشگاه سه گانه و SPARQL → تمام اطلاعات را در قالب عبارات سه بخشی ذخیره کنید
- موضوع
- محمول
- شیء
- مثال: جان گوستان موز
-
مدل “لوسی در لندن زندگی می کند”.
_:lucy a :Person. _:lucy :name "Lucy". _:lucy :bornIn _:idaho. _:idaho a :Location. _:idaho :name "Idaho". _:idaho :type "state". _:idaho :within _:usa. _:usa a :Location. _:usa :name "United States". _:usa :type "country". _:usa :within _:namerica. _:namerica a :Location. _:namerica :name "North America". _:namerica :type "continent".
- توجه → Web3 (وب معنایی) بر اساس آن مدل است
